<re_irc>
<@nihal.pasham:matrix.org> So, been trying to figure out `inline-asm in rust`. I have these 3 (c-type) assembly instructions which I'd like to write in inline asm.
<re_irc>
<@nihal.pasham:matrix.org> damn, I wish I asked earlier. would have saved me a lot of time. thanks
<re_irc>
<@adamgreig:matrix.org> nihal.pasham: you can have the compiler do your register assignment too if you want, rather than picking x1/x2 etc manually, can help the compiler pick good registers if you don't need specific control
<re_irc>
<@adamgreig:matrix.org> but you should always tell the compiler if you are clobbering a register using like a `lateout` arg
<re_irc>
<@nihal.pasham:matrix.org> yeah, thanks. I picked the registers to help with debugging. There's no clobbering - at least as far I can tell (from my debugging output)
<re_irc>
<@adamgreig:matrix.org> clobbering means your asm overwrites the value of a register, which you do to x4, x5, x3, x2, x1, and x0, right?
<re_irc>
<@adamgreig:matrix.org> in each of those cases you should nominally tell the compiler you're writing into those registers so it can save anything it otherwise placed there
<re_irc>
<@ryan-summers:matrix.org> You actually are clobbering registers based on your code
<re_irc>
<@adamgreig:matrix.org> (I appreciate in this case maybe it's moot because you later jump to some random other part of the code so who cares what the compiler thinks)
<re_irc>
<@ryan-summers:matrix.org> You have no guarantees that rust won't be using x4/x5 between asm calls etc.
<re_irc>
<@ryan-summers:matrix.org> It might reorder things
<re_irc>
<@adamgreig:matrix.org> yea, definitely combine the asm calls together when you're relying on named registers in between calls
<re_irc>
<@ryan-summers:matrix.org> Depending on what's around those asms. It should rectify if you do it all in one block and specify clobbers though
<re_irc>
<@adamgreig:matrix.org> I would let the compiler pick registers for you whenever possible, which also resolves most questions about whether you need to specify clobbers
<re_irc>
<@adamgreig:matrix.org> (sometimes you still will if a register that's not explicitly used is still clobbered by a particular instruction of course)
<re_irc>
<@ryan-summers:matrix.org> I didn't know rust let you do that. Pretty neat :)
<re_irc>
<@adamgreig:matrix.org> better yet you can give them all helpful names
<re_irc>
<@adamgreig:matrix.org> or by default it just numbers then 0-n
<re_irc>
<@ryan-summers:matrix.org> Oooh I like that a lot. You just declare a "variable" in assembly land
<re_irc>
<@adamgreig:matrix.org> or you can refer to the arguments with numbers
<re_irc>
<@adamgreig:matrix.org> yea, it's really nice I think
<re_irc>
<@adamgreig:matrix.org> check __enable_icache below for an example of unnamed arguments just being referred to by position
<re_irc>
<@adamgreig:matrix.org> same as format strings in fact
<re_irc>
<@nihal.pasham:matrix.org> adamgreig: so, after these inline instructions, we're basically jumping to the linux kernel (never to return). So, I assumed this should be fine but I see your point on clobbering
<re_irc>
<@nihal.pasham:matrix.org> adamgreig: combining asm calls works. I get this as the output
<re_irc>
<@ubik:matrix.org> I assume `0xfffffffc` is an invalid memory address
<re_irc>
<@ubik:matrix.org> also, why won't GDB let me read any memory? grrrrr.
<re_irc>
<@ubik:matrix.org> `0x1ff968a8`
<re_irc>
<@adamgreig:matrix.org> 0xFFFF_FFF9 is an exception return code meaning "return to thread mode, using msp after return, no floating point state"
<re_irc>
<@adamgreig:matrix.org> so it's not just some random invalid memory address
<re_irc>
<@adamgreig:matrix.org> (or, well, it could be that too of course)
<re_irc>
<@ubik:matrix.org> `MSP` is `0x1ff968a8`.
<re_irc>
<@ubik:matrix.org> that doesn't look like valid memory either.
<re_irc>
<@ubik:matrix.org> BTW, is there an easy way to check where my static vars are being allocated?
<re_irc>
<@adamgreig:matrix.org> `cargo nm` after installing `cargo-binutils`
<re_irc>
<@ubik:matrix.org> thanks!
<re_irc>
<@adamgreig:matrix.org> (don't forget to pass --release etc, you could also use arm-none-eabi-nm on the output elf if you have it installed)
<re_irc>
<@adamgreig:matrix.org> cortex-m v0.7.4 published
<re_irc>
<@adamgreig:matrix.org> looking forward to dumping all the outlined asm stuff once 1.59 comes out with stable asm
<re_irc>
<@adamgreig:matrix.org> with some luck we can do that on cortex-m-rt as well and dump the arm-none-eabi-gcc in its build system too
<re_irc>
<@adamgreig:matrix.org> and that also opens the door to templating the reset vector via cargo features
<re_irc>
<@adamgreig:matrix.org> or maybe even some kind of wild build system shennanigans to enable bss/initialisation of additional memory sections
<re_irc>
<@ubik:matrix.org> hm... can `singleton!` somehow cause such a HardFault?
<re_irc>
<@ryan-summers:matrix.org> singleton allocates the object on the stack and then moves it into the static storage, so if your object is large, you may exceed memory bounds
<re_irc>
<@ubik:matrix.org> Hm... That could be it.
<re_irc>
<@ubik:matrix.org> Well, it's 1024 bytes, not enormous.
<Lumpio->
Then again Rust has been known to use stack very liberally at times
<Lumpio->
Maybe allocating the buffer multiple times as it's passed around
<Lumpio->
People are working on it though.
<re_irc>
<@ubik:matrix.org> any way I can get a `&'static mut [u8; N]` without `singleton!`?
<re_irc>
<@k900:0upti.me> Box::leak it?
<re_irc>
<@k900:0upti.me> Probably not a good idea though
<re_irc>
<@ubik:matrix.org> I don't have a heap allocator right now, so can't even box it. That second option might work indeed
emerent_ has joined #rust-embedded
emerent has quit [Killed (calcium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
mightypork_ has joined #rust-embedded
cr1901_ has joined #rust-embedded
jackneilll has quit [*.net *.split]
ni has quit [*.net *.split]
inara has quit [*.net *.split]
jasperw has quit [*.net *.split]
darknighte has quit [*.net *.split]
jasperw has joined #rust-embedded
<re_irc>
<@ubik:matrix.org> anyway, same result, so it's not that :/
SanchayanMaity_ has joined #rust-embedded
Socke has quit [Ping timeout: 240 seconds]
jasperw- has quit [Ping timeout: 240 seconds]
SanchayanMaity has quit [Ping timeout: 240 seconds]
tafa has quit [Ping timeout: 240 seconds]
cr1901 has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Ping timeout: 240 seconds]
SanchayanMaity_ is now known as SanchayanMaity
GenTooMan has joined #rust-embedded
tafa has joined #rust-embedded
starblue has quit [*.net *.split]
procton has quit [*.net *.split]
mightypork has quit [*.net *.split]
Socke has joined #rust-embedded
starblue has joined #rust-embedded
inara has joined #rust-embedded
darknighte has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> Just declare a static mut array and take a mut ref
<re_irc>
<@adamgreig:matrix.org> Needs unsafe but should make it clear if this is the problem
crabbedhaloablut has quit [Quit: crabbedhaloablut]
crabbedhaloablut has joined #rust-embedded
rardiol has joined #rust-embedded
<re_irc>
<@ubik:matrix.org> Yeah, it's not that.
<re_irc>
<@ubik:matrix.org> I am completely lost
<re_irc>
<@ubik:matrix.org> OK, it seems like the stack pointer is already wrong (!) at the beginning of the program. The RAM starts at `0x20000000` but the MSP is at `0x1ffeaf3c` at boot time.