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
<AdamHott[m]> from what I'm reading a treiber stack doesn't require x86, but that cfg(target_has_atomic) might not have existed at the time.
<AdamHott[m]> cfg(target_has_atomic) configuration option was stabilized in Rust 1.61.0
<AdamHott[m]> released on May 19, 2022
<AdamHott[m]> Architectures like ARM or RISC-V may have weaker memory ordering models that require explicit memory barriers to ensure the correct visibility of operations across threads.
SunClonus has quit [Read error: Connection reset by peer]
SunClonus has joined #rust-embedded
SunClonus has quit [Client Quit]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
GabeR[m] has quit [Quit: Idle timeout reached: 172800s]
linfax has joined #rust-embedded
MathiasKoch[m] has quit [Ping timeout: 246 seconds]
thumbcore[m] has quit [Ping timeout: 260 seconds]
dirbaio[m] has quit [Ping timeout: 256 seconds]
MathiasKoch[m] has joined #rust-embedded
thumbcore[m] has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
DanielakaCyReVol has joined #rust-embedded
<DanielakaCyReVol> <AdamHott[m]> " Architectures like ARM or RISC..." <- Re RISC-V, Daniel Mangum has summarized it:
<JamesMunns[m]> I don't think this is a basic memory ordering question :)
<JamesMunns[m]> I believe the heapless docs uses to talk about the issue of the trieber stack and it's issues with the ABA problem: https://en.wikipedia.org/wiki/Treiber_stack#Correctness
<JamesMunns[m]> specifically it was the difference between LL/SC atomics and whatever x86_64 does (indirect ops?), IIRC
<JamesMunns[m]> there was a "do you feel lucky" section
<JamesMunns[m]> I'm unsure why this was removed in 0.8, but maybe someone figured it out?
<JamesMunns[m]> Specifically Arm has exclusive operations, e.g. LDREX/STREX (and some new ones in thumbv8 iirc), that CAN guarantee freedom from ABA problem, as it can guarantee an exclusive memory bus lock at a hardware level that x86 cannot
<JamesMunns[m]> (in this case, not all cases of the ABA problem)
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> * https://github.com/rust-embedded/heapless/issues/180 notes an issue with it
<JamesMunns[m]> * https://github.com/rust-embedded/heapless/pull/315 is the reimpl that removed the limitations
<JamesMunns[m]> There is some mention of doing the work in asm? I'm unsure.
<JamesMunns[m]> > I didn't have time to look into that. CAS semantics does not produce a sound treiber stack because of the ABA problem; you need LL/SC intrinsics for a sound implementation
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> Anyway left my comment with some info: https://github.com/rust-embedded/heapless/pull/458#issuecomment-1963979576
<JamesMunns[m]> idk if it's sound, too cursed for me.
<whitequark[cis]> it's impossible to soundly use LL/SC from something like C, the architectural requirements for it require the use of assembly
<whitequark[cis]> and even then it's tricky
<dirbaio[m]> hmm wtf
crabbedhaloablut has joined #rust-embedded
<whitequark[cis]> no not like that
<whitequark[cis]> you need the asm block to contain both the ldrex and strex
<JamesMunns[m]> no comment if it's CORRECT, but it has been done manually with asm for llsc targets
<whitequark[cis]> otherwise the C compiler is free to generate code that violates architectural requirements of ll/sc
<whitequark[cis]> (there's a reason ll/sc fell out of favor)
<JamesMunns[m]> Yeah... idk why that isn't one asm blob
<JamesMunns[m]> Ah because trait methods and stuff
<JamesMunns[m]> idk, definitely way above my pay grade, if Catherine looks at it and says "no, bad", i'm likely to defer.
<JamesMunns[m]> This isn't even relevant to dirbaio's question, x86 platforms use "cas with hax", which is a different impl
<JamesMunns[m]> (essentially there's the llsc impl and double-ptr cas impls)
<JamesMunns[m]> the PR in question is only re double-ptr cas
<JamesMunns[m]> but probably good to note that the llsc impl is still questionable
<whitequark[cis]> you can think of LDREX and STREX as parts of a single instruction rather than entirely encapsulated separate instructions
<whitequark[cis]> a bit like how the it block works
<dirbaio[m]> yeah I agree the llsc asm looks sus, lol
<whitequark[cis]> if you put them in the same asm block, you can make sure that (a) they are close enough and (b) there is nothing that will interfere in between, in which case the architecture actually gives you, for example, forward progress guarantees
<whitequark[cis]> take a look at this, for example: https://groups.google.com/g/llvm-dev/c/8Lqai9yf3Q8
<dirbaio[m]> but
<dirbaio[m]> back to the non-LLSC impl
<dirbaio[m]> is that sound on all archs? as long as you do the "double-ptr" trick?
<JamesMunns[m]> I think the trick (IIUC) is not ordering specific, it's just "can you CAS a ptr+tag at the same time"
<dirbaio[m]> (the original docs for x64 seem to apply to an older impl that used AtomicU64, so no double-ptrs
<dirbaio[m]> * no double-ptrs)
<JamesMunns[m]> there's no code comments so it's hard to tell, but it looks like that
<dirbaio[m]> so iiuc with double-ptrs its just plain old CAS and it should always be sound?
<JamesMunns[m]> it's still sort of weak to ABA, but like "spin for 2^64 tag attempts" unlikely
<dirbaio[m]> the heapless pool is so complicated lol
<dirbaio[m]> the inner guts are complicated, the public API is complicated :D
<JamesMunns[m]> https://en.wikipedia.org/wiki/ABA_problem#Workarounds the first solution LOOKS like what is being implemented here
<JamesMunns[m]> in which case, yes, using a tag with double-ptr-cas should be good
<JamesMunns[m]> idk if the impl is right lol, but I can see what japaric was going for.
<JamesMunns[m]> I love the "it's sound because at 60 bits it'll take 10 years and your PC will probably crash/reboot before then" analysis
<JamesMunns[m]> > However, it has been observed that on currently existing CPUs, and using 60-bit tags, no wraparound is possible as long as the program lifetime (that is, without restarting the program) is limited to 10 years; in addition, it was argued that for practical purposes it is usually sufficient to have 40-48 bits of tag to guarantee against wrapping around
<JamesMunns[m]> love computers
<dirbaio[m]> lol
<dirbaio[m]> yea, TIL AtomicU126 is a thing
<dirbaio[m]> nightly-only tho :(
<dirbaio[m]> so uh
<dirbaio[m]> merge? :P
<JamesMunns[m]> ¯\_(ツ)_/¯
<JamesMunns[m]> (for x86_64 linux above)
<dirbaio[m]> to debug these, this command is helpful cargo tree --target riscv32imc-unknown-none-elf --format '{p} {f}'
<dirbaio[m]> shows which crates in the dep tree have which features
<dirbaio[m]> so you can try to see why alloc is being enabled
<AdamHott[m]> oh wow this is what I've been missing in life!
<dirbaio[m]> in this case seems you have a dep on gimli directly
<dirbaio[m]> ```toml
<dirbaio[m]> why is that? you typically don't use gimli in firmwares, only in the host (it's a crate for parsing ELF files and stuff, you typically don't need the firmware to "parse itself")
<dirbaio[m]> can you try removing it?
<AdamHott[m]> when I ran into the errors asking for std, I used cargo build -Zbuild-std --target riscv32imc-unknown-none-elf and I got the error pointing to gimli. So I tried to disable standard in gimli, but that didn't work because it needs alloc
dne has quit [Remote host closed the connection]
<AdamHott[m]> I got confused because I thought all embedded projects are no_std, but it seems from the embassy docs and some info in the ESP Book, that some projects will be std. Wondered what's up with that?
dne has joined #rust-embedded
<dirbaio[m]> adding [dependencies.gimli] default-features = false won't disable default features. you're adding a dep and declaring you don't need default features, but they will still be enabled if another crate depends on gimli with default-features=true. features are ORed together
<AdamHott[m]> ah ok that makes sense now
<AdamHott[m]> I removed gimli and ran "cargo esp32c3" and it gives me an error looking for std because of slab
<dirbaio[m]> espressif has two ways of writing Rust for their chip:
<dirbaio[m]> - using `esp-hal`+`esp-wifi`, which works on top of the hardware directly. with this you don't have `std`. this is the same way Rust support works for most other chips (stm32, nrf...)
<dirbaio[m]> - using `esp-idf-hal`, which works on top of their C RTOS. it has a port of rust's `std`, so you *can* use (a restricted version of) `std` as if you were programming for linux
<dirbaio[m]> embassy works on top of the latter (you can use on top of esp-idf-hal too but I wouldn't recommend it)
<dirbaio[m]> AdamHott[m]: cool, then look at `cargo tree` again and try to find out what's bringing in `slab`
<AdamHott[m]> ok thanks, I'm pulling from this example to build my own stand-alone application, do you know what these examples use? esp-idf-hal, or esp-hal + esp-wifi? https://github.com/esp-rs/esp-wifi/blob/main/esp-wifi/docs/examples.md
<dirbaio[m]> esp-wifi+esp-hal
<dirbaio[m]> you can see in Cargo.toml
<dirbaio[m]> 🙃
<dirbaio[m]> (esp-idf-hal has its own support for wifi based on the C RTOS, it doesn't use/need esp-wifi, so your'e not using that)
mabez[m] has joined #rust-embedded
<mabez[m]> Adam Hott We have a project generator: https://github.com/esp-rs/esp-template which might be useful if you're struggling to get going :)
<mabez[m]> Other than that, hop in https://matrix.to/#/#esp-rs:matrix.org and we can help
<AdamHott[m]> Ah that's great mabez I've been searching for a project generator!
<AdamHott[m]> ok I'll hop in esp-rs!
<mabez[m]> You'll still need to take snippets from examples etc, but it should set you up with the right dependencies to get you going :)
<AdamHott[m]> ok awesome! thanks dirbaio that tree command is priceless
korken89[m] has joined #rust-embedded
<korken89[m]> Hey James Munns, I've been playing around a bit with `postcard-rpc` now and like it. The thing that I'm wondering about it that it's built on `Schema` which is experimental in `postcard`, would it be possible to elaborate on how experimental it is?
<korken89[m]> I mean, will `postcard-rpc` maybe stop working in the future if `Schema` is considered bad?
<korken89[m]> I
<korken89[m]> s/I/It seems to work well in my limited testing./
<JamesMunns[m]> Schema is almost certain to work long term, it might just have breakages or tweaks if we realize something is wrong
<JamesMunns[m]> Like adding a field or something
<JamesMunns[m]> Until postcard RPC idk if anyone was actually using it at all, I wouldn't be surprised by bugs
<JamesMunns[m]> But I want the schema tools unless someone proves it is unsound
<JamesMunns[m]> Or if there's a better way to expose it
<JamesMunns[m]> I might see if I can make it a separate crate in the postcard 2 release
<JamesMunns[m]> Then I'll just cut a non 1.0 release for that crate
<korken89[m]> Alright, thanks for the insight!
<JamesMunns[m]> It just wasn't stable enough to call it 1.0 when postcard 1.0 released
<korken89[m]> The thing I have to get a better understanding for now is the dispatcher and add_handler works together in detail :)
<korken89[m]> Using them is simple enough!
<korken89[m]> I'm going to make a small embassy-net UDP + postcard-rpc to test it out with now.
<JamesMunns[m]> tbh I don't love the dispatcher for async
<JamesMunns[m]> it's good for blocking handlers, but not async ones.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PvsjTlumwGXtJqetrVYUBCno>)
<JamesMunns[m]> basically blocking is good if:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vSRRMDmEzKGYMsbgJJDmjAAE>)
<JamesMunns[m]> unfortunately since every future is a unique type, there's no way to have an async dispatch table, shy of basically a big match statement.
<JamesMunns[m]> (very open to suggestions here)
<korken89[m]> Right, and async traits is not enough?
<korken89[m]> Ah each future will be unique so you can't store it
<JamesMunns[m]> yep
<JamesMunns[m]> you could do it with like `Box<dyn async trait>`, but :/
<JamesMunns[m]> or more like `fn() -> Box<impl Future>` or something, idk
<JamesMunns[m]> that's my current sort of code setup, it's not great, and requires a kind of two-step decode.
<JamesMunns[m]> you could probably macro around it, but I don't love it
IlPalazzo-ojiisa has joined #rust-embedded
<korken89[m]> Looks like my old manual enum based RPC code :D
<JamesMunns[m]> yeah, and that makes me sad
<JamesMunns[m]> tho it does mean you don't need a single large enum to exist on the stack
<JamesMunns[m]> and the key is better than the enum - it detects schema changes, so you don't have "accidentally successful" decodes.
<JamesMunns[m]> but ux wise, yeah.
<JamesMunns[m]> very open to ideas.
<korken89[m]> I'll start with my UDP test code so I can actually sets stuff :) Then I can start giving some feedback!
<korken89[m]> s/sets/test/
<korken89[m]> I mean, spontaneously a macro sounds not super horrible
<korken89[m]> I'm thinking similar to tokio::select!
<JamesMunns[m]> yeah
<JamesMunns[m]> basically a macro that looks like a normal match but does extra decoding/error checking steps
<JamesMunns[m]> or at least some way to get access to the seq no, maybe the key
<JamesMunns[m]> anyway, those are my ideas, if you make something neat I'm probably in :)
<korken89[m]> Yeah, looks quite nice to me
<korken89[m]> i'
<korken89[m]> * I'll see where I land :D
<korken89[m]> I just don't want to make my 10th home hacked RPC system again, so getting at least part of it abstracted is a win in my view
<JamesMunns[m]> yep
<JamesMunns[m]> i've built a ton, and just never had a great way to make it an abstraction
<JamesMunns[m]> I think postcard-rpc fixes some, but not all of those problems :D
<korken89[m]> Just googling to find answers is even hard enough, RPC or Command/Response interface, Topics or unsolicited messages, ...
<korken89[m]> The terminology is all over the place
<JamesMunns[m]> yep. I went with topics, because I've worked with MQTT, but this isn't a lot like mqtt
ruabmbua[m] has quit [Quit: Idle timeout reached: 172800s]
<korken89[m]> The Only Truth Is The Documentation (And Sometimes The Code) ™️
<JamesMunns[m]> Next: define what counts as "embedded" :)
<korken89[m]> :D
linfax has quit [Ping timeout: 246 seconds]
Rahix has quit [Quit: ZNC - https://znc.in]
WSalmon has quit [*.net *.split]
Ranhir has quit [*.net *.split]
Socke has quit [*.net *.split]
pbsds has quit [*.net *.split]
dnm has quit [*.net *.split]
AdamHorden has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
lockna has quit [*.net *.split]
zagura has quit [*.net *.split]
kenny has quit [*.net *.split]
cr1901 has quit [*.net *.split]
limpkin has quit [*.net *.split]
stephe has quit [*.net *.split]
sigmaris has quit [*.net *.split]
stgl has quit [*.net *.split]
exark has quit [*.net *.split]
fooker has quit [*.net *.split]
diagprov has quit [*.net *.split]
NishanthMenon has quit [*.net *.split]
dirbaio[m] has quit [*.net *.split]
MathiasKoch[m] has quit [*.net *.split]
danielb[m] has quit [*.net *.split]
edm has quit [*.net *.split]
ni has quit [*.net *.split]
seds has quit [*.net *.split]
thomas25 has quit [*.net *.split]
jsolano has quit [*.net *.split]
xnor has quit [*.net *.split]
IlPalazzo-ojiisa has quit [*.net *.split]
hmw has quit [*.net *.split]
nohit has quit [*.net *.split]
pflanze has quit [*.net *.split]
richardeoin has quit [*.net *.split]
DanielakaCyReVol has quit [*.net *.split]
vollbrecht[m] has quit [*.net *.split]
JamesMunns[m] has quit [*.net *.split]
inara has quit [*.net *.split]
agg has quit [*.net *.split]
_catircservices has quit [*.net *.split]
Abhishek_ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
sauce has quit [*.net *.split]
wose has quit [*.net *.split]
barafael[m] has quit [*.net *.split]
whitequark[cis] has quit [*.net *.split]
vancz has quit [*.net *.split]
Amanieu_ has quit [*.net *.split]
Shell has quit [*.net *.split]
Darius has quit [*.net *.split]
dne has quit [*.net *.split]
firefrommoonligh has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
jr-oss has quit [*.net *.split]
corecode has quit [*.net *.split]
sknebel has quit [*.net *.split]
dav1d has quit [*.net *.split]
ello has quit [*.net *.split]
AdamHott[m] has quit [*.net *.split]
Allie has quit [*.net *.split]
Ekho has quit [*.net *.split]
HumanG33k has quit [*.net *.split]
a2800276 has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
mightypork has quit [*.net *.split]
jasperw has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
tafa has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
dreamcat4 has quit [*.net *.split]
Dr_Who has quit [*.net *.split]
mathu has quit [*.net *.split]
thumbcore[m] has quit [Ping timeout: 264 seconds]
GenTooMan has quit [Ping timeout: 264 seconds]
mabez[m] has quit [Ping timeout: 264 seconds]
barnabyw[m] has quit [Ping timeout: 264 seconds]
StephenD[m] has quit [Ping timeout: 264 seconds]
thejpster[m] has quit [Ping timeout: 264 seconds]
thumbcore[m] has joined #rust-embedded
Rahix_ has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
DanielakaCyReVol has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
dne has joined #rust-embedded
MathiasKoch[m] has joined #rust-embedded
danielb[m] has joined #rust-embedded
tafa has joined #rust-embedded
vollbrecht[m] has joined #rust-embedded
pbsds has joined #rust-embedded
barafael[m] has joined #rust-embedded
whitequark[cis] has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
dnm has joined #rust-embedded
firefrommoonligh has joined #rust-embedded
dreamcat4 has joined #rust-embedded
ello has joined #rust-embedded
cr1901 has joined #rust-embedded
Ranhir has joined #rust-embedded
AdamHott[m] has joined #rust-embedded
jsolano has joined #rust-embedded
WSalmon has joined #rust-embedded
Dr_Who has joined #rust-embedded
JamesMunns[m] has joined #rust-embedded
_catircservices has joined #rust-embedded
Foxyloxy has joined #rust-embedded
sigmaris has joined #rust-embedded
kenny has joined #rust-embedded
AdamHorden has joined #rust-embedded
vancz has joined #rust-embedded
Darius has joined #rust-embedded
edm has joined #rust-embedded
Allie has joined #rust-embedded
hmw has joined #rust-embedded
Abhishek_ has joined #rust-embedded
jr-oss has joined #rust-embedded
nohit has joined #rust-embedded
ni has joined #rust-embedded
limpkin has joined #rust-embedded
cyrozap has joined #rust-embedded
Socke has joined #rust-embedded
pflanze has joined #rust-embedded
corecode has joined #rust-embedded
inara has joined #rust-embedded
sknebel has joined #rust-embedded
xnor has joined #rust-embedded
Lumpio- has joined #rust-embedded
Ekho has joined #rust-embedded
m5zs7k has joined #rust-embedded
mathu has joined #rust-embedded
mightypork has joined #rust-embedded
jasperw has joined #rust-embedded
a2800276 has joined #rust-embedded
dav1d has joined #rust-embedded
Amanieu_ has joined #rust-embedded
Shell has joined #rust-embedded
sauce has joined #rust-embedded
wose has joined #rust-embedded
HumanG33k has joined #rust-embedded
agg has joined #rust-embedded
seds has joined #rust-embedded
richardeoin has joined #rust-embedded
thomas25 has joined #rust-embedded
stephe has joined #rust-embedded
exark has joined #rust-embedded
diagprov has joined #rust-embedded
fooker has joined #rust-embedded
NishanthMenon has joined #rust-embedded
lockna has joined #rust-embedded
zagura has joined #rust-embedded
stgl has joined #rust-embedded
thejpster[m] has joined #rust-embedded
barnabyw[m] has joined #rust-embedded
StephenD[m] has joined #rust-embedded
GenTooMan has joined #rust-embedded
mabez[m] has joined #rust-embedded
spinfast[m] has joined #rust-embedded
<spinfast[m]> What’s the code size cost for async vs non async stuff, has anyone here done any comparisons?
<JamesMunns[m]> "it depends"
<JamesMunns[m]> Honestly - there's likely no way to reasonably quantify that, it's not like async has some specific ratio of overhead
<JamesMunns[m]> there are some aspects of async code that are less well optimized than non-async, for example nesting futures can sometimes increase the size of tasks more than should be necessary, though this is RAM usage not code usage
<JamesMunns[m]> but async (in the model that Rust has chosen) is not a model that has inherent amounts of overhead
<JamesMunns[m]> I've written an async bootloader that fit in <4k of code size
<dirbaio[m]> it's about the same size as hand-written state machines
<dirbaio[m]> * async code is about the same size as equivalent hand-written state machines
<dirbaio[m]> because that's what the compiler is doing, writing state machines for oyu
<dirbaio[m]> it's "zero cost" in that sense, you don't pay any cost vs writing state machines by hand
<dirbaio[m]> but
<dirbaio[m]> you do pay some cost vs actually fully blocking code, because the bookkeeping of saving/restoring the state and yielding is not free
riskable[m] has joined #rust-embedded
<riskable[m]> I opened up a project I haven't worked on in a while and I'm having a strange problem: cargo build works fine but rust analyzer does not. I mean, it works for some things but completely fails to detect problems when I change the versions of things in Cargo.toml (as in, I know I need to change some stuff when I upgrade to certain new crates but those related errors aren't seen by rust analyzer)
<riskable[m]> When I check its output in Visual Studio Code I see: error: failed to run custom build command for 'libusb1-sys v0.6.4'
<riskable[m]> I have all the dependencies for libusb1-sys and hidapi v1.5.0 (another error of the same type) so I'm not sure why rust analyzer can't figure things out 🤷
<riskable[m]> In my settings.json I have:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zZmklsZNTeFPDDmnDsrPbzaF>)
<JamesMunns[m]> Is this a workspace? Like do you have std code and nostd code in the same project?
<JamesMunns[m]> Like, are you trying to build libusb for a thumbv7m target?
<riskable[m]> JamesMunns[m]: It's a workspace. It's all no_std for the most part except for two build-dependencies. I posted the `Cargo.toml` here: https://gist.github.com/riskable/6cd65856eb87d2d3b2788433b441d25a
<spinfast[m]> <dirbaio[m]> "you do pay some cost vs actually..." <- I mean that's true with threads as well saving registers and what not
<spinfast[m]> * with threads/rtos, * stuff as well
Ralph[m] has joined #rust-embedded
<Ralph[m]> i by chance just stumbled across https://docs.rust-embedded.org/book/intro/no-std.html and noted that it's still referencing `alloc-cortex-m` (which is now `embedded-alloc`). probably it's just enough to update the link, but maybe it's worth to write more about it since AFAIK it's now completely cortex/ARM-independent and can thus be used anywhere? i also noticed that the `embedded-alloc` github repo still has e.g. `arm` & `cortex-m`
<Ralph[m]> as topics (right sidebar, under the description) - might make sense to make this more generic as well?
<Ralph[m]> either way, i'm leaving this to somebody who's familiar with `embedded-alloc`
IlPalazzo-ojiisa has quit [Quit: Leaving.]