<cr1901> text data bss dec hex filename
<cr1901> 1992 4 46 2042 7fa target/msp430-none-elf/release/at2x
<cr1901> 1942 during the last CI build. There may be ways to get that down to what LLVM/GCC does in the future, I'm not too worried about it rn
<cr1901> Additionally, there was at least one linker relaxation opportunity lost by the size increase
<cr1901> Amanieu: If you want an example 1/2
<cr1901> Old: fa6c:d0 43 93 07 mov.b#1,0x0793;r3 As==01, PC rel. 0x0201
<cr1901> New:
<cr1901> fa6e:3e 40 01 02 mov#513,r14;#0x0201
<cr1901> fa72:5f 43 mov.b#1,r15;r3 As==01
<cr1901> fa74:ce 4f 00 00 mov.br15,0(r14);
<cr1901> 4 bytes vs 10 :)
<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> (and discarding it)
<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> ... That is not the code block I hoped it would be, sorry
<re_irc> <@larunite:matrix.org> can i format a code block in here? triple backticks doesnt work?
<re_irc> <@k900:0upti.me> Might be worth asking the r-a people
<re_irc> <@k900:0upti.me> Definitely looks like a bug
<re_irc> <@larunite:matrix.org> Dang :/
<re_irc> <@larunite:matrix.org> Aha! The problem was that I was inside `main()`, which was annotated with the cortex_m `#[entry]`
<re_irc> <@larunite:matrix.org> #[entry]
<re_irc> <@larunite:matrix.org> If I refactor it into
<re_irc> <@larunite:matrix.org> fn entry() -> !{
<re_irc> <@larunite:matrix.org> main();
<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> <@larunite:matrix.org> rust-analyzer version: 1d563133b 2022-01-22 nightly
<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.
<re_irc> <@adamgreig:matrix.org> huh, I haven't seen this version of our logo before :P https://www.oreilly.com/library/view/getting-started-with/9781484277898/
<re_irc> <@jamesmunns:beeper.com> Yeah, me neither actually
<re_irc> <@jamesmunns:beeper.com> I wonder if they comply with the license :p
<re_irc> <@adamgreig:matrix.org> i like to imagine apress/springer check these sorts of things
<cr1901> Amanieu: Okay, time to write tests! I'm using mips-types as a template >>
<cr1901> https://github.com/rust-lang/rust/blob/master/src/test/assembly/asm/mips-types.rs#L1-L6 These appear to be magic comments, is there a reference to what they all mean? Yes, most are obvious but still
<cr1901> i.e. Idk the difference between e.g. MIPS32-LABEL, and CHECK-LABEL
<cr1901> I guess #APP/#NO_APP are guards so the tests know which lines to compare
<Amanieu> It's basically to support both mips32 and mips64 from one file. You don't need that.
<Amanieu> Have a look at avr for example, it doesn't use the revisions feature.
<Amanieu> Basically CHECK-* applies to all revisions, MIPS32-* only applies to the mips32 version.
<cr1901> The APP/NO_APP lines seem to use the assembler comment token
<cr1901> ";" for AVR, '#" for MIPS
<cr1901> https://github.com/rust-lang/rust/blob/master/src/test/assembly/asm/avr-types.rs#L11-L18 Why are these lines required? And why do the macros still work anyway even if we redefine them?
<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?
<cr1901> Amanieu: So, in the msp430 crate, I have things like this: https://github.com/rust-embedded/msp430/blob/new-asm/src/register/pc.rs#L6-L19
<cr1901> At the same time, I don't allow users to put "R0"-"R4" into inline asm expressions
<cr1901> I guess my question is: Is there a way to allow them as literals but not as Rust allocating them manually
<cr1901> (As in "you're on your own if you do this")
<Amanieu> What exactly are you trying to do? Isn't R0 the program counter?
<cr1901> Indeed :D. I should prob get rid of these old asm expressions
<cr1901> I don't think anyone ever used them, they were added "just because"
<cr1901> On the other hand, there might be legitimate reasons to update SP (think of Variable length arrays, for instance)
<Amanieu> No, absolutely not.
<Amanieu> You must restore SP to its original value at the end of an asm!.
* cr1901 snickers
<Amanieu> You can have temporary allocations inside the asm!, as long as you restore SP afterwards.
<cr1901> https://github.com/rust-embedded/msp430/blob/new-asm/src/register/sr.rs Reading the status register is harmless, right?
<Amanieu> Yes.
<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.
<Amanieu> Here's the long list of things you are/aren't allowed to do with asm!: https://doc.rust-lang.org/nightly/reference/inline-assembly.html#rules-for-inline-assembly
<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
<cr1901> and was told "Absolutely not."
<re_irc> <@jamesmunns:beeper.com> (context, for other Matrix folks that might be confused: https://libera.irclog.whitequark.org/rust-embedded/2022-01-22)
<re_irc> <@xiretza:xiretza.xyz> yeah this is really weird, it looks like the bridge just really doesn't like Amanieu haha
<cr1901> Irony... IRC has been more fruitful than Matrix the past few days
<Amanieu> :(
<re_irc> <@jamesmunns:beeper.com> We <3 you, even if the bridge doesn't Amanieu.
<lambda> (test message please ignore)
<re_irc> <@xiretza:xiretza.xyz> that came through ^
<cr1901> Amanieu: So, modifying SP is insta-UB, while modifying PC is legal if enters another asm block?
<cr1901> Btw, tests are written and I'm updating the unstable book. So we should be good to go in a bit
<Amanieu> Modifying PC is legal if you enter another asm block and then later come back to the original block. The wording there is a bit confusing.
<Amanieu> Basically it's meant to allow stack switching using inline asm, and not much else.
<cr1901> Amanieu: It's ready... are you up for taking a look before I squash and make a PR?
<Amanieu> sure
<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.
<cr1901> All the registers I pass from the Rust side of things are one-to-one equiv w/ LLVM
<Amanieu> But it seems that LLVM is perfectly happy to accept an i8 in a full-sized register, so there's no need for that.
<Amanieu> Just remove the rXb aliases entirely.
<cr1901> Will do
<cr1901> >LLVM is perfectly happy to accept an i8
<cr1901> Yea I saw that somewhere in the LLVM backend code 2 nights ago, but can't find it now
<Amanieu> And finally, you messed up the submodules. You'll need to fix that before making a PR.
<cr1901> which ones :P?
<Amanieu> src/doc/* and src/tools/rust-analyzer
<cr1901> Hmmm I apparently did that today