<cr1901>
But everything looks fine... I'm satisfied/will do a physical test tonight or tomorrow
<Amanieu>
Let me know if you want me to review the rustc side in the meantime.
<cr1901>
Sure, I would appreciate some more feedback on whether I should remove the reg_byte class and other nits.
<cr1901>
I don't _think_ I'll have to modify the compiler proper anymore. Just add tests.
<Amanieu>
Definitely remove reg_byte
<cr1901>
Will do
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<cr1901>
Amanieu: Last update for the night :D... real firmware works w/ the new asm! macro :D!
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> are you on cortex-m? if you just want a short busy wait, you could use cortex_m::asm::delay(n)
<re_irc>
<@gpanders:matrix.org> yes I am, thanks. I will try that
<re_irc>
<@adamgreig:matrix.org> in a more general sense to avoid the loop being optimised away there's a bunch of things you could put in the body; in rust accesses are volatile instead of variables, so e.g. you could `for _ in 0..100 { core::ptr::read_volatile(0 as *const u32) }` but it's a bit wordy (and `unsafe`)
<re_irc>
<@adamgreig:matrix.org> so a common placeholder is cortex_m::asm::nop() on cortex-m at least
<re_irc>
<@adamgreig:matrix.org> but at that point you really may as well use cortex_m::asm::delay()
<re_irc>
<@gpanders:matrix.org> delay looks like exactly what I wanted :)
<re_irc>
<@adamgreig:matrix.org> register access are volatile, so you could do like `for _ in 0..100 { adc.sr.read() }` or something too I guess
<re_irc>
<@adamgreig:matrix.org> cool :)
<re_irc>
<@adamgreig:matrix.org> you might consider in this case reading the actual ADC value like 5 times
<re_irc>
<@adamgreig:matrix.org> nice sort of self-timed option, and clearly can't be removed by the compiler
smach has joined #rust-embedded
smach has quit [Remote host closed the connection]
<re_irc>
<@larunite:matrix.org> Hello all. I'm trying to explore embedded rust a bit, and I'm using vscode as my editor. It all works, but rust-analyzer is throwing a tantrum incredibly often. Even just writing `let p = hal::pac::Peripherals::take().unwrap();` causes RA to panic with a failed request.
<re_irc>
<@larunite:matrix.org> This is making discoverability pretty much non existent - I can't get any sort of autocomplete or suggestions, not even docs a decent amount of the time. It's rather limiting me to just copying from examples.
<re_irc>
<@larunite:matrix.org> Is this a known thing or is there something wrong with my configuration?
<re_irc>
<@k900:0upti.me> That's definitely not normal
<re_irc>
<@larunite:matrix.org> The RALS terminal finishes with:
<re_irc>
<@larunite:matrix.org> ``` thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\chalk-solve-0.75.0\src\clauses\builtin_traits\fn_family.rs:91:55
<re_irc>
<@larunite:matrix.org> stack backtrace:
<re_irc>
<@larunite:matrix.org> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
<re_irc>
<@larunite:matrix.org> RA behaves properly
<re_irc>
<@adamgreig:matrix.org> George: hmmm, I don't think that should foil r-a, a lot of people here use it and as far as I know without that problem (and it works for me inside `#[entry]` but in vim not vscode)
<re_irc>
<@adamgreig:matrix.org> is it an up-to-date r-a release?
<re_irc>
<@larunite:matrix.org> the r-a extension is up to date. I can try and work out the underlying version
<re_irc>
<@adamgreig:matrix.org> should be ok.. :/
<re_irc>
<@adamgreig:matrix.org> if you clone something like https://github.com/rust-embedded/cortex-m-quickstart/ (and in Cargo.toml change the {{project_name}} to something without braces), does it work inside main there?
<re_irc>
<@larunite:matrix.org> So I'm not getting the full ra panic trace anymore, since i updated to rust 1.58
<re_irc>
<@larunite:matrix.org> but it still doesn't autocomplete how id expect
<re_irc>
<@larunite:matrix.org> but if i'm not operating directly within #[entry#
<re_irc>
<@adamgreig:matrix.org> not outright panicking is something at least! I'm not sure about the autocomplete, maybe someone else who uses it will be along
<re_irc>
<@larunite:matrix.org> It doesn't super surprise me, cos I guess the macro expansion fails when the contained code is not valid (ie half way through typing a line) so RA has a hard time
<re_irc>
<@larunite:matrix.org> but I am surprised that it would work inconsistently for you and me
<re_irc>
<@adamgreig:matrix.org> (I don't use r-a autocomplete)
<re_irc>
<@larunite:matrix.org> ah i see sorry
<re_irc>
<@larunite:matrix.org> the mostest recentist, yep :P
<re_irc>
<@jamesmunns:beeper.com> Gotcha
<re_irc>
<@jamesmunns:beeper.com> I gotta run for a bit, but I can try repro'ing later.
<Amanieu>
Because these tests use #![no_core] so there is no core crate.
<Amanieu>
It's to avoid having to compile core for every target we test inline assembly on.
<Amanieu>
The magic is in the #[rustc_builtin_macro] attribute, it recognizes the macro by name and implements it internally.
<Amanieu>
The contents of the macro_rules! is ignored.
<cr1901>
Interesting/weird :o
<cr1901>
Amanieu: So, is the assembler actually run as part of these tests, or does the test harness just look at what's between the APP/NO_APP lines after emitting the assembler input?
<Amanieu>
Yes it is run. Essentially the resulting assembly string is parsed by LLVM's integrated assembler. Later, we emit a full disassembly from LLVM's internal assembler representation. So asm parse errors are still caught.
<cr1901>
> Later, we emit a full disassembly from LLVM's internal assembler representation
<cr1901>
The optional -Cemit-asm compiler flag?
<cr1901>
I probably typed that wrong
<cr1901>
I'm thinking --emit=obj, etc, but that full disassembly that's emitted is always done when compiling a binary/lib/etc?
<Amanieu>
The restrictions on r0-r4 are only about using them as in/out operands. Inside the asm! you can do whatever you want.
lambda has joined #rust-embedded
<cr1901>
Well, I'll get rid of the SP/PC register write/read functions before cutting a release
<cr1901>
Amanieu: That also answered my follow up... SR can't be written to, but dint/eint will set/clear a bit in the SR under programmer control (interrupt enable)
<cr1901>
so I thought maybe somehow asm! needed to know about that (not really)
<cr1901>
You seem horrified that I would try such stack shenanigans :)
<Amanieu>
Because I have seen so many people try them and "it seems to work fine" are famous last words.
<cr1901>
Seems reasonable. How do you exit an asm block that has already been exited (without first entering it again)?
<re_irc>
<@jamesmunns:beeper.com> cr1901 your messages are getting bridged to matrix, but I don't see any of Amanieu's, so it looks like you've been monologue'ing for the last three hours :D
<re_irc>
<@jamesmunns:beeper.com> (CC adamgreig for ops)
<cr1901>
I suggested using inline asm for implementing VLAs
<Amanieu>
Does it make sense to support rXb as aliases? I believe you said that notation is only used within LLVM internals are nowhere else.
<cr1901>
It's an LLVM register class; I interpreted some of your feedback as that I had to at least pass rXb down to the LLVM layer since LLVM knows about them
<cr1901>
Lemme find the message
<Amanieu>
Ah no, I meant that you may need to add some register name translation in the back-end. Nothing that is exposed to users though.