ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
dav1d has quit [Ping timeout: 252 seconds]
dav1d has joined #rust-embedded
<Kert[m]> <firefrommoonligh> "(The answer here btw, is get a..." <- Cortex-m, same thing https://gist.github.com/kaidokert/307bcd99ead724528286e9b43acf3543
<Kert[m]> I'm not sure i remember why this one is more convoluted.
<Kert[m]> By the way, cortex-m-rt feature "paint-stack" also does paint the stack for you: https://docs.rs/crate/cortex-m-rt/latest/features
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
_whitelogger has joined #rust-embedded
_whitelogger has joined #rust-embedded
marmrt[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
Farooq has quit [Quit: Idle timeout reached: 172800s]
apirkle8 has joined #rust-embedded
apirkle has quit [Ping timeout: 244 seconds]
apirkle8 is now known as apirkle
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
Alex[m] has quit [Quit: Idle timeout reached: 172800s]
_whitelogger has joined #rust-embedded
ouilemur has joined #rust-embedded
MitchellDScott[m has quit [Quit: Idle timeout reached: 172800s]
<Kin-o-matix[m]> is there a reason the compiler builtin for memcpy is so big?
<Kin-o-matix[m]> * so big on arm cortex-m?
<Kin-o-matix[m]> there's gotta be close to 500+ ops in there
<JamesMunns[m]> Probably just pretty optimized for speed, if I had to guess
<JamesMunns[m]> a lot of "get to stride length, then use the largest copies possible, then handle end of stride length"
<Kin-o-matix[m]> yeah, I get its more efficient to move word at a time for sure, and having to deal with the unaligned copies is a hassle...
<Kin-o-matix[m]> but shockingly big
<Kin-o-matix[m]> nearly 1kb in my release build
<Kin-o-matix[m]> 0.1% 8.8% 744B std compiler_builtins::mem::memcpy
<JamesMunns[m]> I'm surprised CPU designers don't just have a memcpy instruction at the hardware level these days
<Kin-o-matix[m]> there's a peripheral that does this
<JamesMunns[m]> yeah, most chips can do mem2mem copies with DMA
<Kin-o-matix[m]> dma may as well be called memcpy engine
<JamesMunns[m]> yeah, but you need to worry about stride there too 😃
<Kin-o-matix[m]> * memcpy engine/peripheral
<JamesMunns[m]> if you do a 1-byte aligned dma transfer, it's 4x the bus ops that a 4-byte aligned transfer would be
<Kin-o-matix[m]> very true
<Kin-o-matix[m]> the key to this is to never have unaligned things and instead throw exceptions when it happens, fix the janky software by having the hardware give the middle finger to this sort of thing
<Kin-o-matix[m]> bob widlar style
<JamesMunns[m]> I mean, [u8; 64] is not guaranteed to be aligned
<JamesMunns[m]> it is only 1-byte aligned
<JamesMunns[m]> it's not necessarily janky software, just the rules as agreed at a lang level.
<JamesMunns[m]> or if I want to copy from the back 13 bytes of a slice: that's a memcpy
<Kin-o-matix[m]> i feel like rust needs the equivalent of picolibc/newlibc for core, a size focused implementation of this stuff
<Kin-o-matix[m]> it just does not seem size is really considered
<Kin-o-matix[m]> 0.2% 14.8% 1.2KiB std core::str::count::do_count_chars
<JamesMunns[m]> See Dion's `optimize-for-size` attribute, which is an early attempt to allow for stuff like that.
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]> <JamesMunns[m]> "I'm surprised CPU designers don..." <- Most regular CPUs do, but apparently not small Cortex
<KevinPFleming[m]> <Kin-o-matix[m]> "is there a reason the compiler..." <- An open coded loop in my application is about 70% smaller
<TomB[m]> Yeah the memcpy I see when building with zephyr is like 28 bytes
<TomB[m]> So, that seems massive and surprising
<KevinPFleming[m]> still true with rust 1.88; if i build using the open-coded loop the .text section is more than 1K smaller than if use the 'copy_within' function from the slice traits
Alex[m] has joined #rust-embedded
<Alex[m]> <JamesMunns[m]> "See Dion's `optimize-for-size..." <- Isn’t it now `optimize(size/speed/none)`? I remembered it so.