<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'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]>
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
<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
<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
<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`
<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]>
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
<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 🤷
<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`