<Lumpio->
What so they removed UART recv support and now ADC too?
<re_irc>
<@bugadani:matrix.org> Lumpio-: Things can be added back later but changing something is a lot harder.
<Lumpio->
My favorite way to advertise embedded Rust to people was talking about how it's the one platform where there's actually a real cross-platform interface for peripherals so that you can write portable drivers, but if they keep removing those interfaces one by one I might have to stop talking about that
<Lumpio->
I know it wasn't perfect but it was better than nothing...
<re_irc>
<@bugadani:matrix.org> Lumpio-: You can still use/implement the traits from 0.2.7, they don't go anywhere
<Lumpio->
Or will they when all the HAL crates start updating
<re_irc>
<@larunite:matrix.org> The embedded hal interfaces were a cool idea but did they ever really hold up in practice?
<Lumpio->
Not in all cases no
<re_irc>
<@eldruin:matrix.org> It is indeed unfortunate that we had to remove so many traits for the 1.0 release. You can find the reasoning here (https://github.com/rust-embedded/embedded-hal/issues/357). If you are interested in bringing back a particular crate, you are most encouraged to comment in the issues about your use case and make proposals
<re_irc>
<@eldruin:matrix.org> * trait,
<re_irc>
<@eldruin:matrix.org> * highly
<re_irc>
<@crespum:matrix.org> I've just realized how valuable the discussions on the GH issues are. Cheers for that!
<Lumpio->
Oh man that's a lot of stuff getting the axe
<Lumpio->
I've been out of the loop because they're making me do all the embedded stuff in C at work
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 246 seconds]
<re_irc>
<@chrysn:matrix.org> I remember that years ago there was talk of a MCU project that'd use, like, 16 rv32e cores that would all not even have an interrupt controller, but instead would be clock gated by some interrupt style signal. The concept was advertised IIRC along the lines of "why deal with all the complexity of storing registers, switching stack etc when you can just put 16 very small cores in there, plus you don't have to worry about...
<re_irc>
... interrupt priorities because there's a core for each source".
<re_irc>
I didn't manage to find the project in search engines based on what I remember of it -- do you remember, and could help me out here? And: Did anything come of it? (Sounded quite researchy then).
<re_irc>
<@9names:matrix.org> sounds a lot like the parallax propeller tbh, though that isn't rv32e
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> : no relation at all
<re_irc>
<@chrysn:matrix.org> Mh, the term "cog" for the core does ring a bell, either that was an inspiration or I did mix things up.
<re_irc>
they kinda hide the architecture a bit when you develop for it, but i just found this:
<re_irc>
<@9names:matrix.org> the other thing it reminded me of is XCORE (the XMOS thing).
<re_irc>
<@9names:matrix.org> apparently their 4th-gen chips are riscv based!
<re_irc>
<@chrysn:matrix.org> That looks more like 16 harts spread across 2 cores, but that can probably give similar properties with the right scheduling.
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<re_irc>
<@9names:matrix.org> i would expect there's enough compute in each of those cores to keep a decent number of those threads active under the right workloads
<re_irc>
<@chrysn:matrix.org> Yes, but unlike with the cogs they'll only get to run an instruction once every 8 cycles when doing round-robin, or (likely not given how they boast on determinism) as the hart scheduler sees fit.
<re_irc>
<@chrysn:matrix.org> Which, when picking scheduling, puts you back into the dilemma of picking interrupt priorities.
<re_irc>
<@chrysn:matrix.org> And if, as indicated in the diagram, the pipeline is not part of the hart but of the core, then the power savings of a dormant core are somewhat negated, because the pipeline will have to load the next executable instruction (the first thing to do when the interrupt condition happens) in advance every 8 cycles, just in case that hart is awoken between preloading and triggering. (Can be mitigated, but then wakeup config is...
<re_irc>
... more complex, and times even a bit less deterministic).
<re_irc>
<@bugadani:matrix.org> So are we RTOS yet?
<re_irc>
<@jamesmunns:beeper.com> I mean there's a couple of RTOSs and pseudo-RTOSs too for a quite a while now
<re_irc>
<@jamesmunns:beeper.com> tock-os predates the embedded-wg, iirc, and is very much a classic style rtos, albeit with a bit of a "container-like" twist
<re_irc>
<@dirbaio:matrix.org> yes, we are RTOS! 😠
<re_irc>
<@jamesmunns:beeper.com> I should probably PR that, mnemos doesn't compile on stable anymore, it uses "impl_trait_in_assoc_type"
<re_irc>
<@jamesmunns:beeper.com> it doesn't _have_ to, I guess, but it makes life less painful, and I just keep telling myself it is gunna be stable this year lol
<re_irc>
<@bugadani:matrix.org> Unstable feature-limbo is one of my pain points for sure...
<re_irc>
<@dirbaio:matrix.org> that's missing esp-idf-hal too (yea it's not Rust but it's the same kind as freertos-rust which is listed there)
<re_irc>
<@dirbaio:matrix.org> target for rust 1.73 👀
<re_irc>
<@dirbaio:matrix.org> and then hopefully "type_alias_impl_trait", "impl_trait_in_assoc_type" soon after
<re_irc>
<@chrysn:matrix.org> I still find the proposed return type notation weird (would have expected a builtin type "ReturnOf<impl FnOnce>"), but hey, if it gets things done 🤷
<re_irc>
<@dirbaio:matrix.org> yeah, I find it weird too
<re_irc>
<@dirbaio:matrix.org> there's also the alternative of doing "F::Output" (the Output associated type of the "Fn", "FnOnce", "FnMut" traits)
<re_irc>
<@dirbaio:matrix.org> which is arguably more "rusty" because i'ts not new synta
<re_irc>
<@dirbaio:matrix.org> * syntax
<re_irc>
<@chrysn:matrix.org> I think I'd like that even better. (I've used something like this when extracting return types from named function types in C APIs).
<re_irc>
<@dirbaio:matrix.org> but OTOH the "Fn*" traits have a special syntax for where bounds already, so... 🤷
<re_irc>
because no multicore executors
<re_irc>
<@dirbaio:matrix.org> luckily the AFIT Send bounds is literally not a problem for us in embedded :D
<re_irc>
<@dirbaio:matrix.org> like, AFIT is used everywhere in Embassy already and there's been literally zero problems with it
<re_irc>
<@bugadani:matrix.org> : yet
<re_irc>
<@chrysn:matrix.org> : Well _looks at agenda_
<re_irc>
<@dirbaio:matrix.org> multicore executors would be a very strange thing in embedded
<re_irc>
<@chrysn:matrix.org> Well, the executor I'm playing with on RIOT is not multicore, but multithreaded, so it could work with Send items.
<re_irc>
<@dirbaio:matrix.org> multicore MCUs typically are designed so you assign each core to a different purpose
<re_irc>
<@dirbaio:matrix.org> they often have different architecture, core features, frequency, dedicated RAM/flash, different peripherals
<re_irc>
<@dirbaio:matrix.org> so you can't "pool" them into a multicore executor anyway
<re_irc>
<@dirbaio:matrix.org> : why'd you want a multithreaded executor on a singlecore chip?
<re_irc>
<@chrysn:matrix.org> : Not necessarily. The Cortex-M33 / M0 are typical big-little tools. But the next generation of XMOS XCORE appears to have 16 Harts in 2 cores, and at least their whitepaper does have pooling applications.
<re_irc>
<@dirbaio:matrix.org> these chips are very exotic tho
<re_irc>
<@chrysn:matrix.org> : Because my OS doesn't have non-blocking versions of all the calls yet, and running multithreaded executors (when threads are already a thing) is a cheap way out.
<re_irc>
_ducks in shame_
<re_irc>
<@dirbaio:matrix.org> haha, okay :D
<re_irc>
<@jamesmunns:beeper.com> Yeah, the mnemos kernel is currently all single threaded, I plan to have userspace threads/processes, but the kernel itself will likely be single threaded for a while. That being said, I'll eventually have to figure out what to do with multiple cores
<re_irc>
<@jamesmunns:beeper.com> (I'll definitely have _processes_ for userspace, not sure if/when I'll support _threads_, tbh)
<re_irc>
<@chrysn:matrix.org> Also, if different task priorities are involved, I could well imagine that it might be reasonable to process some tasks in interrupts even though they were previously processed outside of an ISR. Not sure that really needs Send, but at least there is preemption (and thus it's worth considering whether Send is needed).
<re_irc>
<@chrysn:matrix.org> : I've been talking of "threads" because that's what the OS calls them; could just as well say "processes", but given there is no isolation, the former seems more suitable.
<re_irc>
<@jamesmunns:beeper.com> Yeah, for mnemos there would be isolation, so comms would either need to go through the kernel, or something ipc-shaped
<re_irc>
<@jamesmunns:beeper.com> (I'm targeting chips with MMUs/MPUs tho, I know RIOT has a much wider (and lower) charter)
<re_irc>
<@jamesmunns:beeper.com> (userspace doesn't really _exist_ today, so take this as more hopes and dreams than fact, but that's what I'm planning lol)
<re_irc>
<@chrysn:matrix.org> It's definitely a win for resilience to have good isolation instead of shared memory. When any of our threads crash, chances of recovering are neigh zero. (At best we can limp on, but eventually, reboot).
<re_irc>
<@jamesmunns:beeper.com> Yeah, the safety critical bar of isolation is "spatial and temporal"
<re_irc>
<@jamesmunns:beeper.com> which means you have memory/resource protection, and also a scheduler that can pre-empt threads/processes
<re_irc>
<@jamesmunns:beeper.com> async is hard to do either - it's a shared stack and cooperative multitasking
<re_irc>
<@jamesmunns:beeper.com> so, mnemos probably won't have any kernel isolation for now, but at least spatial + temporal isolation process-to-process and process-to-kernel.
<re_irc>
<@chrysn:matrix.org> I'd low-key expect all safety critical state machines to be handled in drivers (state machines running in ISRs) anyway; async is then adding high-level features.
<re_irc>
<@jamesmunns:beeper.com> also, mnemos is very much not ever going to be safety critical :D
<re_irc>
<@jamesmunns:beeper.com> just where a lot of my theory knowledge is from lol
<re_irc>
<@jamesmunns:beeper.com> I guess never say never, it'd probably be easier than linux, but a lot harder than making a case for like RTIC or something lol
<re_irc>
<@chrysn:matrix.org> The spatial isolation for async is probably no harder than for blocking code, right? Around the polling of a task, memory protection is set up to only allow access to the stack, that task's mutable state, and any shared memory.
<re_irc>
<@dirbaio:matrix.org> : as long as you never poll the same task from separate thrads/ISRs then this wouldn't require Send. I.e. if a particular task is _only_ polled from one iSR, that's not sending it
<re_irc>
<@jamesmunns:beeper.com> how do you pause an async task without having separate stacks
<re_irc>
<@dirbaio:matrix.org> (you'd need Send/Sync for sharing _data_ between tasks, but the futures themselves don't need to be Send/Sync)
<re_irc>
<@jamesmunns:beeper.com> like, you can't "force yield" an async task without having a separate stack/context to jump to.
<re_irc>
<@jamesmunns:beeper.com> oh sorry, you said spatial
<re_irc>
<@jamesmunns:beeper.com> yeah, maybe! I haven't thought about how you would contextually track what resources the task has access to
<re_irc>
<@jamesmunns:beeper.com> you'd need some metadata somewhere to track what each task should be allowed to access, and the executor would need to set it up on entry and tear it down on exit
* re_irc
@chrysn:matrix.org : bends his mind for any plausible situation in which polling would first be done in an ISR and later on a different one
<re_irc>
<@jamesmunns:beeper.com> mnemos uses some intrusive types which I think might not play nice with what I said above
<re_irc>
<@dirbaio:matrix.org> : you could even do that without Send/Sync, as long as all ISRs are at the same prio! :D
<re_irc>
<@jamesmunns:beeper.com> tho you probably wouldn't want to use intrusive types for something you expected spatial partitioning for lol
<re_irc>
<@jamesmunns:beeper.com> Specifically, we have sort of oneshot channel where the storage is in the task itself, so when another task "sends" to that task, it inserts it directly into the memory of the receiving task
<re_irc>
<@jamesmunns:beeper.com> which, is very much not partitioning lol
<re_irc>
<@chrysn:matrix.org> : It might even work with different prios as long as the task is protected by the executor against concurrent execution. (Or the executor might use that knowledge to shift priorities, but that's priority-inversion-mitigation level stuff, and I'm trying to keep my hands off that, as it's sometimes just bad design).
<re_irc>
<@dirbaio:matrix.org> : that's unsound if you define Send/Sync threads as "RTOS thread or interrupt priority level"
<re_irc>
<@chrysn:matrix.org> : Yeah, LLs and that kind are part of what makes it messy to take down a RIOT thread.
<re_irc>
<@dirbaio:matrix.org> code that uses unsafe internally but offers a public safe API might rely on that.
<re_irc>
<@jamesmunns:beeper.com> I think I have another intrusive thingy like that somewhere else, but I can't remember where.
<re_irc>
<@chrysn:matrix.org> : Right. (I even regularly use a ZST that's specifically for that, should have thought of it before typing).
<re_irc>
memory protection is overrated for Rust firmwares. Memory protection has 2 advantages:
<re_irc>
but Rust firmwares... simply don't have memory corruption bugs.
<re_irc>
<@dirbaio:matrix.org> 🌶️ hot take 🌶️
<re_irc>
- Easier debugging, if one task has memory corruption bugs it will crash faster and more localized.
<re_irc>
- Contain the damage if one task has memory corruption bugs and gets maliciously exploited
<re_irc>
<@jamesmunns:beeper.com> : This is fair - but safety critical also cares about hardware failure and things like single event upsets
<re_irc>
<@dirbaio:matrix.org> (the only legit use case for memory protection in a Rust firmware is if you're actively running untrusted "apps", say in a smwartwatch OS)
<re_irc>
<@jamesmunns:beeper.com> from a design perspective, you are right
<re_irc>
<@jamesmunns:beeper.com> also hardware isolation is a second layer of protection if you ever got your unsafe code wrong
<re_irc>
<@chrysn:matrix.org> : I wonder whether with a trusted compilation process and allowing unsafe only in known-sound libraries, you might get around even that.
<re_irc>
<@jamesmunns:beeper.com> like, I totally agree that rust clears the 99% of low hanging fruit, which is miles miles better
<re_irc>
<@chrysn:matrix.org> Chances are not because there's always soundness bugs, but it'd be a nice feature for low-level assurance. (Like, hacking on my watch but being sure I won't brick it).
<re_irc>
<@jamesmunns:beeper.com> but when you have millions of devices in the field and/or millions of operational hours, weird statistically unlikely shit starts happening all the time lol
<re_irc>
<@jamesmunns:beeper.com> (not all devices are safety critical, for sure, just want to make sure someone doesn't over extrapolate your opinion that hardware stuff isn't EVER necessary/useful)
<re_irc>
<@jamesmunns:beeper.com> like, even for safety critical software which has gone through crazy process, you still have fail-safe hardware outside the MCU, and a watchdog which smacks the MCU in the worst case
<re_irc>
<@jamesmunns:beeper.com> but again, this is all "system safety" rather than "software safety"
<re_irc>
<@jamesmunns:beeper.com> : I'd probably say it's cutting another xx% of issues out, but the swiss cheese approach exists for a reason :)
<re_irc>
<@dirbaio:matrix.org> if you care about cosmic rays, imo you could get more ROI from ECC ram/flash or running multiple MCUs concurrently synchronized
<re_irc>
<@dirbaio:matrix.org> than to take on the massive complexity of using the MPU
<re_irc>
<@jamesmunns:beeper.com> : These are different techniques that address some overlapping root causes! There is no one-size fits all approach to safety :D
<re_irc>
<@dirbaio:matrix.org> plus, the cool thing about Rust async is you can have RTOS-like ergonomics (tasks, mutexes, channels, priority) without the costs (context-switching, multiple stacks..)
<re_irc>
<@jamesmunns:beeper.com> I mean don't get me wrong, I am writing my whole kernel as basically an async scheduler lol
<re_irc>
<@jamesmunns:beeper.com> I'm _sold_ on async and rust. It's just good to keep a level head on what it does and doesn't get you.
<re_irc>
<@dirbaio:matrix.org> if you're going to use a RTOS with stackful tasks anyway then you're paying for _both_ the cost of a context-switching kernel _and_ an async executor which kinda defeats the point
<re_irc>
<@jamesmunns:beeper.com> : This I sorta agree with. I'd probably run an async task inside a single thread, rather than the other way around
<re_irc>
<@jamesmunns:beeper.com> is much more familiar with RIOT and whatever the integration target is though :)
<re_irc>
<@chrysn:matrix.org> : As soon as there are computationally bound tasks involved that are not easily written with resumption in mind, I'm not sure there are good altenatives.
<re_irc>
<@dirbaio:matrix.org> you can run computationally-bound tasks at a lower priority, io-bound async tasks at a higher priority
<re_irc>
<@dirbaio:matrix.org> embassy uses the NVIC for this
<re_irc>
<@chrysn:matrix.org> Then again, if all goes as I hope, there might be one task group per interrupt level (of which ideally there is only a small number), and the stack switching for those is handled by the MCU's hardware efficiently.
<re_irc>
<@dirbaio:matrix.org> kinda similar to RTIC
<re_irc>
<@dirbaio:matrix.org> single stack, no context-switching kernel, but you still have preemption and compute-bound code doesn't prevent higher-prio tasks from running
* re_irc
@chrysn:matrix.org is going to read through it to see how it is single-stack
<re_irc>
<@jamesmunns:beeper.com> it's basically threadpools but stacked on top of each other
<re_irc>
<@chrysn:matrix.org> (or is it single-stack just in non-ISR mode?)
<re_irc>
<@jamesmunns:beeper.com> when the higher prio thread pool is empty, its not running
<re_irc>
<@dirbaio:matrix.org> higher-prio tasks run in ISR mode
<re_irc>
<@jamesmunns:beeper.com> but as soon as there is a task in the higher prio threadpool, the lower prio thread is interrupted and the higher one runs to completion
<re_irc>
<@chrysn:matrix.org> OK, but ISRs also do have their own stack, so once more there is one stack per level.
<re_irc>
<@jamesmunns:beeper.com> nope
<re_irc>
<@jamesmunns:beeper.com> same stack
<re_irc>
<@dirbaio:matrix.org> no, ISRs push more frames on the one task
<re_irc>
<@dirbaio:matrix.org> * stack
<re_irc>
<@jamesmunns:beeper.com> the lower one's CAN'T run until the upper ones are done.
<re_irc>
<@jamesmunns:beeper.com> * ones
<re_irc>
<@chrysn:matrix.org> : Oh right, that's a possible configuration too on cortex MCUs.
<re_irc>
<@jamesmunns:beeper.com> but this doesn't let you have two tasks that share time slices, higher prio always wins.
<re_irc>
<@jamesmunns:beeper.com> oh, I shouldn't say "to completion", I should say "to yield"
<re_irc>
<@jamesmunns:beeper.com> which is actually a benefit over rticv1 for things like priority inversion, where the high prio task is waiting for something from the low prio task
<re_irc>
<@jamesmunns:beeper.com> in async, you can yield from the high prio task to give the low prio task a chance to make forward progress, but as soon as the high prio task is reawoken, it runs for as long as it wants.
<re_irc>
<@jamesmunns:beeper.com> so you could sorta do something like tokio's "spawn_blocking", where you spawn that task on the lowest priority executor
<re_irc>
<@chrysn:matrix.org> I'll have to read some more of embassy code to understand how doing stacks-on-top-of-each-other is simplifying things compared to stacks-next-to-each-other.
<re_irc>
<@jamesmunns:beeper.com> basically, "context switching is cheaper"
<re_irc>
<@jamesmunns:beeper.com> and less overhead in right-sizing separate stacks
<re_irc>
<@jamesmunns:beeper.com> there is only THE stack
<re_irc>
<@chrysn:matrix.org> My gut feeling is that separate stacks are way easier to debug.
<re_irc>
<@chrysn:matrix.org> But does that making right-sizing easier or harder?
<re_irc>
<@chrysn:matrix.org> With two stacks, I can watch both run through their most complex code path, observe the high-water-mark patterns I've put in there, and then be somewhat confident that I won't get overflows.
<re_irc>
<@jamesmunns:beeper.com> it's not markedly worse in async, I suppose, you're still summing the worst case of all tasks
<re_irc>
<@chrysn:matrix.org> With stacked stacks, I'll only observe the maximum if the interrupt hits right when the idle task hits the maximum, and that could only be happening in production.
<re_irc>
<@jamesmunns:beeper.com> (at least for static analysis)
<re_irc>
<@chrysn:matrix.org> And what's the cost of switching the stack? Should be an instruction or a handful for stack pointer change.
<re_irc>
<@dirbaio:matrix.org> in an ideal rainbow fairy tale world, "cargo-call-stack" would work and tell you your max stack usage 🥲
<re_irc>
<@jamesmunns:beeper.com> : with no memory protection, yes
<re_irc>
<@chrysn:matrix.org> (The costly part is storing away the registers, and that is what the MCU does at interrupt time anyway)
<re_irc>
<@jamesmunns:beeper.com> with memory protection, you have to swap mpu/mmu configs on every context switch
<re_irc>
<@chrysn:matrix.org> : With memory protection, you'd still need to protect the "underlying" stack if you're serious about it.
<re_irc>
<@dirbaio:matrix.org> also in the shared stack scenario, the RAM usage for stack is "max(tasks at prio 0) + max(tasks at prio 1) + max(tasks at prio 2)"
<re_irc>
<@chrysn:matrix.org> : So pray we all. Haven't gotten it running yet.
<re_irc>
<@dirbaio:matrix.org> vs with separate stacks it is "sum(tasks at prio 0) + sum(tasks at prio 1) + sum(tasks at prio 2)"
<re_irc>
<@dirbaio:matrix.org> which is more
<re_irc>
<@dirbaio:matrix.org> (this is a bit apples-to-oranges because async tasks also need RAM for the futures though)
<re_irc>
<@jamesmunns:beeper.com> in theory, interrupt based pre-emption like rtic/embassy-multiprio is a _little cheaper_, because you aren't doing the:
<re_irc>
- interrupt
<re_irc>
- context switch out of task
<re_irc>
- resume
<re_irc>
- context switch into task
<re_irc>
<@jamesmunns:beeper.com> its just:
<re_irc>
- interrupt
<re_irc>
- poll current executor
<re_irc>
<@jamesmunns:beeper.com> but tbh, hopefully not a lot more expensive, other than figuring out "what thread do I swap to", which you don't have to think about in the "strictly prio ordered" model of rticv1 or embassy-multiprio
<re_irc>
<@jamesmunns:beeper.com> but, as noted before, you can't straight up stop or kill a task in async like you can in embassy
<re_irc>
<@jamesmunns:beeper.com> but I guess the tradeoff is "you shouldn't have to, if you don't have bugs"
<re_irc>
<@jamesmunns:beeper.com> (and I agree with dirbaio, for MOST firmware projects, this is a better default choice, but I will say I don't think it's ALWAYS the right choice - sometimes you do want failable/recoverable stuff more granular than "reboot the whole system" for many reasons)
<re_irc>
Any documentation or may be some links would be useful.
<re_irc>
Any one have tried Rust on HPCs ?
<re_irc>
I am trying to see some security use case development on HPCs with Rust
<re_irc>
<@anand21:matrix.org> Hi all,
<re_irc>
<@jamesmunns:beeper.com> HPCs like "high performance computing"?
<re_irc>
<@dirbaio:matrix.org> High Pin Count SoCs
<re_irc>
<@dirbaio:matrix.org> (jk)
<re_irc>
<@jamesmunns:beeper.com> Allwinner D1 is an LFBGA-337 :p
<re_irc>
<@anand21:matrix.org> Yes High performance computing.
<re_irc>
Sorry didn’t provided the context
<re_irc>
<@jamesmunns:beeper.com> I haven't seen anything personally, googling "rust in hpc" did turn up a couple of papers, blog articles, and reddit discussions, but no personal experiences.
<re_irc>
<@jamesmunns:beeper.com> * experience from me at least
<re_irc>
<@jamesmunns:beeper.com> Most of the papers look like "could we use it for HPC? Seems so", than "here's how we use it for some huge pipeline"
<re_irc>
<@jamesmunns:beeper.com> a lot of the papers I found are VERY simple "we printed numbers in a for loop, heres C/C++/Rust", or some very naive approaches to parallelism, which is disappointing, but expected I guess
<re_irc>
<@k900:conduit.0upti.me> Why are you asking this in an embedded room
<re_irc>
<@jamesmunns:beeper.com> So for now, it probably comes down to:
<re_irc>
- Do you need to compile for some esoteric supercomputer architecture? If not, then it's totally fine, if so, it might be some work
<re_irc>
- Do you need some esoteric (or not so esoteric) library for doing matrix math/some specific analysis? If so: depends, if not: it's totally fine
<re_irc>
<@jamesmunns:beeper.com> K900: Some HPC can be weird target wise (and this room might actually be helpful), IMO.
<re_irc>
<@jamesmunns:beeper.com> Otherwise yeah, it might make sense to also check out the discord/zulip other forums as well
<re_irc>
<@k900:conduit.0upti.me> I don't think anyone is doing HPC on particularly weird targets?
<re_irc>
<@k900:conduit.0upti.me> Like, maybe sparc or s390x
<re_irc>
<@k900:conduit.0upti.me> But those are surprisingly well supported in LLVM
<re_irc>
<@jamesmunns:beeper.com> Yeah, I dunno much about hpc, tbh. Are they all running linux these days?
<re_irc>
<@jamesmunns:beeper.com> > according to TOP500 list that keeps track of world's most powerful computer systems. All TOP500 supercomputers run Linux
<re_irc>
<@k900:conduit.0upti.me> But I'm guessing people just run linux/390x on them
<re_irc>
<@k900:conduit.0upti.me> These days
<re_irc>
<@k900:conduit.0upti.me> That or they're so committed to the IBM stack that they won't use Rust anyway
<re_irc>
<@thejpster:matrix.org> I've taught Rust to IBM.=
<re_irc>
<@thejpster:matrix.org> * IBM.
<re_irc>
<@thejpster:matrix.org> And arguably oxide.computer is all about HPC? Or at least it's about hyperscale things with a bazillion cores per rack.
cr1901_ is now known as cr1901
richardeoin has quit [Ping timeout: 240 seconds]
richardeoin has joined #rust-embedded
bpye has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> @room meeting time again! agenda is https://hackmd.io/tMoPuNmNThW2zP_xLwFEmg, please add anything you'd like to announce or discuss, we'll start in a few minutes :)
<re_irc>
<@jamesmunns:beeper.com> I hope everyone has had a good week!
<re_irc>
<@adamgreig:matrix.org> it's been sooo hot, of course the week i'm running around outside instead of sitting in the air-conditioned office :P
<re_irc>
<@adamgreig:matrix.org> ok, let's start! I don't have any announcements this week, does anyone else?
<re_irc>
<@jamesmunns:beeper.com> I set up a new room, #mnemos-dev:beeper.com (https://matrix.to/#/#mnemos-dev:beeper.com), if anyone is interested in following along with the development for that, or has an questions (context on what mnemos is (https://onevariable.com/blog/mnemos-moment-1/)
<re_irc>
<@jamesmunns:beeper.com> anyone's welcome to join :)
<re_irc>
<@jamesmunns:beeper.com> I set up a new room, #mnemos-dev:beeper.com (https://matrix.to/#/#mnemos-dev:beeper.com), if anyone is interested in following along with the development for that, or has questions (context on what mnemos is (https://onevariable.com/blog/mnemos-moment-1/))
<re_irc>
<@thejpster:matrix.org> The Launching Pad team is meeting tonight at 20:30 London Time. I'll report back from your sibling not-teams next week.
<re_irc>
<@thejpster:matrix.org> I have thoughts about ejecting us from the Rust Project because you don't actually affect any compiler or library stuff - but these thoughts are not well formed.
<re_irc>
<@jamesmunns:beeper.com> : I don't totally comprehend this statement, are you saying someone is thinking of ejecting us, or you think we should eject ourselves?
<re_irc>
<@thejpster:matrix.org> (this is the remit of the Launching Pad, you are either launched as a full team, or you are dropped ... or I find some middle ground.)
<re_irc>
<@thejpster:matrix.org> And specifically, these are my thoughts, no-one elses.
<re_irc>
<@thejpster:matrix.org> But that's not a topic for discussion. The announcement is, the launchpad team is meeting tonight.
<re_irc>
<@thejpster:matrix.org> I'll bring more coherent thoughts later.
<re_irc>
<@adamgreig:matrix.org> _should_ it be a topic for discussion, or are you saying you want to discuss it at some later date when you've thought about it more?
<re_irc>
<@thejpster:matrix.org> yes, sorry, correct, not a topic for now.
<re_irc>
<@thejpster:matrix.org> or specifically, today.
<re_irc>
<@thejpster:matrix.org> later.
<re_irc>
<@jamesmunns:beeper.com> (definitely worth discussing after seeing how the council goes, imo!)
<re_irc>
<@jamesmunns:beeper.com> And thanks again to for being the official mayor of embedded rust :D
<re_irc>
<@thejpster:matrix.org> of all the launching pad sub-teams - async, cli, gamedev, etc.
<re_irc>
<@thejpster:matrix.org> you are but one of my wards
<re_irc>
<@jamesmunns:beeper.com> lmao
<re_irc>
<@jamesmunns:beeper.com> the benelux of rust, to be sure.
<re_irc>
<@therealprof:matrix.org> lol
<re_irc>
<@adamgreig:matrix.org> well, let's move on with the agenda for now, then
<re_irc>
<@adamgreig:matrix.org> transition off bors is continuing apace thanks to 's efforts last week, four more repos moved across
<re_irc>
<@therealprof:matrix.org> How are people liking it so far? It still feels weird to me.
<re_irc>
<@adamgreig:matrix.org> that gives a fairly good template for what it should look like, but with one detail that might be worth briefly discussing - we can have CI run on pushes to all branches (and then have to exclude GH's own pushes to its merge queue branch), or we could only run CI on pushes to master and on PRs and merge queues
<re_irc>
<@therealprof:matrix.org> Do we have a proper setup guide?
<re_irc>
<@adamgreig:matrix.org> in general I feel like CI on pushes to branches is probably worthwhile for long-lived branches like old stable versions of libraries, the same as we check on pushes to master, so I guess it's worth doing that way
<re_irc>
<@adamgreig:matrix.org> : not yet, I think this is probably the last question before having one
<re_irc>
<@adamgreig:matrix.org> so far I like it, the "auto merge" thing is nice and the UI integration is a bit better, though it's a shame to lose the delegation features of bors (and maybe "try" but the CI running anyway more or less covers it)
<re_irc>
<@adamgreig:matrix.org> but with bors.tech going away and self-hosting not an appealing option I don't see that we have much other option anyway :P
<re_irc>
<@adamgreig:matrix.org> I think for a few repos - like a-e-r and wg - we probably don't need mq at all and can just approve and merge pull requests directly
<re_irc>
<@therealprof:matrix.org> Some issues I've run into is that the retry behaviour is totally odd, it's kind of hard to control what goes together and what doesn't (there's this merge group feature I don't quite understand). Also the parallism seems to be so high that in the microbit repo it's easy to run afoul a download limit for the Rust stuff all of a sudden.
<re_irc>
<@adamgreig:matrix.org> interesting, I hadn't noticed the latter but in principle I think it's straightforward to reduce the parallelism - did you not have the same issue on bors?
<re_irc>
<@therealprof:matrix.org> It's not only marked as beta but to me this really feels unfinished...
<re_irc>
<@thejpster:matrix.org> If it doesn't do CI on branches, how do you know the branch in your fork is ready to open a PR with?
<re_irc>
<@therealprof:matrix.org> : Why not open a PR?
<re_irc>
<@thejpster:matrix.org> Yeah, I guess you could open a Draft: one. I just like it to all be green before I tell people I have work I want to share with them.
<re_irc>
<@therealprof:matrix.org> I don't think this will work on branches of forks anyway, that only applies to the main repo itself I think.
<re_irc>
<@adamgreig:matrix.org> ah, yea, I hadn't considered running it on your own fork repo's branch before opening a PR
<re_irc>
<@thejpster:matrix.org> Does the merge queue disable the normal GHA stuff?
<re_irc>
<@adamgreig:matrix.org> I think you can enable GHA for that situation
<re_irc>
<@adamgreig:matrix.org> no, it doesn't, it's separate
<re_irc>
<@adamgreig:matrix.org> (you can use GHMQ without GHA, using an external CI provider)
<re_irc>
<@adamgreig:matrix.org> * provider, for example)
<re_irc>
<@therealprof:matrix.org> While I didn't exactly love bors, I do feel that MQ is actually worse.
<re_irc>
<@adamgreig:matrix.org> would you rather we stop swapping wg repos to it, then?
<re_irc>
<@adamgreig:matrix.org> I'm not sure we have other good options really
<re_irc>
<@therealprof:matrix.org> No, I guess it's fine but I think we might have to do a bit more tinkering with it and/or mitigate shortcomings by not using it as suggested by you before.
<re_irc>
<@adamgreig:matrix.org> ok, next up on the agenda is the book translations, I've kept it so it doesn't get forgotten but there's no real update this week either; does anyone want to discuss it now?
<re_irc>
<@eldruin:matrix.org> is that waiting on anything?
<re_irc>
<@therealprof:matrix.org> I guess everything of importance has been said. It would be good to gauge interest for people wanting to contribute translations though.
<re_irc>
<@adamgreig:matrix.org> I think in principle the PR (https://github.com/rust-embedded/book/pull/356) isn't waiting on anything; we could do some GHA tidying up to help the CI workflow possibly (maybe as another PR)
<re_irc>
<@therealprof:matrix.org> It is adding a bit of complexity in a few dimensions and I think it's only worth the effort if people are actually considering to contribute translations.
<re_irc>
<@adamgreig:matrix.org> I guess ideally someone would be keen enough to see it merged to try it out with a translation, but it's hard to know if having it merged might be what encourages people to use it for translations
<re_irc>
<@therealprof:matrix.org> I think if noone is keen on providing one complete translation, the it's probably not worth it.
<re_irc>
<@therealprof:matrix.org> * then
<re_irc>
<@eldruin:matrix.org> if that is really the biggest stopper, I will adapt or contribute a spanish translation
<re_irc>
<@therealprof:matrix.org> Oooh...
<re_irc>
<@eldruin:matrix.org> I'm not sure if we already have a partial translation in that repo
<re_irc>
<@therealprof:matrix.org> There's a partial translation to Danish I think.
<re_irc>
<@romancardenas:matrix.org> I can help with Spanish too, if needed
<re_irc>
<@adamgreig:matrix.org> if nothing else, putting together a translation inside that framework would be a great way to see how it works in practice and how useful it is, _and_ we'd have a new translation
<re_irc>
<@therealprof:matrix.org> Indeed.
<re_irc>
<@adamgreig:matrix.org> it might be we can work out whether we do want to have translations as a sort of drop-down menu on our hosted copy, or still use pofiles but have them be separate github-pages-hosted books, like the rust project does for its books (and we do currently)
<re_irc>
<@adamgreig:matrix.org> OK, well that's a direction forwards for the translations, thank you!
<re_irc>
<@adamgreig:matrix.org> next up is the cortex-m optional hardfault trampoline PR, I think this is nearly ready to merge (it has tests now) barring one possible bug that's being addressed
<re_irc>
<@eldruin:matrix.org> I hope we do not come up with any more changes 😅
<re_irc>
<@adamgreig:matrix.org> seems like we might well be very close, then!
<re_irc>
<@adamgreig:matrix.org> who wanted to talk about atomic-polyfill?
<re_irc>
<@romancardenas:matrix.org> Me!
<re_irc>
<@adamgreig:matrix.org> go for it
<re_irc>
<@romancardenas:matrix.org> Ok so here's the problem:
<re_irc>
Currently, polyfill assumes that all riscvimac targets implement all the atomic instructions, but... It seems that at least the e310x microcontroller does it partially
<re_irc>
<@romancardenas:matrix.org> It supports load and store operations but it does not support load-reserved and so on
<re_irc>
<@romancardenas:matrix.org> Additionally, the e310x-hal DOES use atomic operations, so it is not possible to compile a project as risv imc
<re_irc>
<@romancardenas:matrix.org> Thus, I think we need a feature or something to force polyfilling for those corner cases
<re_irc>
<@romancardenas:matrix.org> And I'd like to hear from you, sin you might havea better idea
<re_irc>
<@romancardenas:matrix.org> * since
<cr1901>
What's load-reserved?
<re_irc>
<@romancardenas:matrix.org> Basically, it supports simple atomic operations but it does not support read-write-modify operations
<re_irc>
<@mabez:matrix.org> Not suggesting this is a better idea, its certainly not for performance, but if you want an unintrusive (unintrusive as in unintrusive to the dependency graph), you can use https://github.com/esp-rs/riscv-atomic-emulation-trap to seemlessly emulate atomics by trapping on the instruction and emulating it in software
<re_irc>
<@thejpster:matrix.org> Wait, it's IM-A-C but only half an A?
<re_irc>
<@romancardenas:matrix.org> Yes, it seems that that's an option
<cr1901>
This sounds very similar to the RISCV32I-without-A, cortex-m0 and msp430 cases, where a store/load of bus-width or less is atomic.
<cr1901>
portable-atomic and atomic-polyfill handle those cases already (in different ways)
<re_irc>
<@mabez:matrix.org> Note that with the "+a" extension, only cas operations need to be emulated, atomic load/stores etc are emitted as normal word sized load/stores in codegen
<cr1901>
You mean without* the "+a" extension?
<cr1901>
(I figured "+a" provided cas :P)
<re_irc>
<@mabez:matrix.org> Sorry, I meant building with "+a" codegeneration option for a non "a" or non confirming "a" target
<re_irc>
<@mabez:matrix.org> When you lie to LLVM and tell it the target supports the atomic extension you get atomic load/stores for free, only cas has to be emulated
<re_irc>
<@romancardenas:matrix.org> A problem I'm facing is that e310x-hal does import core::sync::atomic, and if I try to build my projects for a riscv imc +a, the import fails
<re_irc>
<@romancardenas:matrix.org> I ended up with my atomic-polyfill fork and adding a feature to force polyfilling everything
<re_irc>
<@romancardenas:matrix.org> But I'd like to use a more standard solution
<re_irc>
<@romancardenas:matrix.org> I'll do thanks!
<re_irc>
<@romancardenas:matrix.org> But for the long term... How should we proceed to fix it? Is it a rusc codegen issue? Or can we do something about it?
<re_irc>
<@adamgreig:matrix.org> (you'll have store/load but not CAS)
<re_irc>
<@romancardenas:matrix.org> And crates such as atomic-polyfill would be able to deal with this elegantly?
<re_irc>
<@romancardenas:matrix.org> Or would we just compile for riscv imc with half A?
<re_irc>
<@mabez:matrix.org> elegantly, no, because it means every crate you wish to add to your crate that uses atomics must be a) aware of this issue b) work around it with atomic_polyfill.
<re_irc>
<@romancardenas:matrix.org> I see, we would need a hybrid atomic-polyfill with real load/stores and fake CAS operations..
<re_irc>
<@romancardenas:matrix.org> (that use critical sections and load stores)
<re_irc>
<@romancardenas:matrix.org> How do you feel about a half-atomic crate for this? And other crates such as atomic-polyfill can use it as a dependency under a feature gate
<re_irc>
<@mabez:matrix.org> To be clear I think atomic_polyfill is a good solution, but its not a general one. It requires other dependencies to be aware of it
<re_irc>
<@mabez:matrix.org> So in your situation you have the following choices:
<re_irc>
1. Add atomic_polyfill to the hal (and any other crates you wish to use)
<re_irc>
2. use the atomic emulation trap handler
<re_irc>
3. Suffer until the problem is fixed upstream in rust
<re_irc>
<@adamgreig:matrix.org> (oops, I got distracted, but that's it for the meeting, thanks everyone!)
<cr1901>
also, isn't atomic_polyfill deprecated in favor of portable_atomic?
<re_irc>
<@jamesmunns:beeper.com> this is the same as cortex-m0 (thumbv6), btw.
<re_irc>
<@jamesmunns:beeper.com> atomic load/stores are just "normal" aligned load/stores
<re_irc>
<@romancardenas:matrix.org> Then I'll open an issue in the e310x crates to transition to riscv-imc
<re_irc>
<@jamesmunns:beeper.com> on arm, the M3/4/7+ all support two extra instructions, "ldrex" and "strex", which enable building CAS options
<re_irc>
<@dirbaio:matrix.org> A adds LR/SC instructions
<re_irc>
which can be used to implement "compare_and_swap", and with that all RMWs (fetch_add, etc)
<re_irc>
<@jamesmunns:beeper.com> I'm guessing +a does the same thing, with whatever it is on riscv (LR/SC I guess?)
<re_irc>
<@dirbaio:matrix.org> IIUC riscv LR/SC is equivalent to arm LDREX/STREX yeah
<re_irc>
<@dirbaio:matrix.org> so there should be no "half A"
<re_irc>
<@dirbaio:matrix.org> your chip is either -imac or -imc
<re_irc>
<@romancardenas:matrix.org> The docs say that it supports LR/SC operations but only on cached memory
<re_irc>
<@jamesmunns:beeper.com> : yeah, that's a hell of a thing to do lol
<re_irc>
<@jamesmunns:beeper.com> Rust has no way to support that, unfortunately.
<re_irc>
<@romancardenas:matrix.org> And the other amo stuff in perioherals and RAM
<re_irc>
<@dirbaio:matrix.org> perhaps it's an initialization issue, the HAL is not enabling the cache or something?
<re_irc>
<@dirbaio:matrix.org> I assume RAM is cacheable?
<re_irc>
<@romancardenas:matrix.org> It is not
<re_irc>
<@dirbaio:matrix.org> and you want to do atomic stuff in RAM?
<re_irc>
<@romancardenas:matrix.org> Well, I run everything on RAM and it breaks
<re_irc>
<@dirbaio:matrix.org> : wat
<re_irc>
<@dirbaio:matrix.org> what's the cache for then? 😂
<re_irc>
<@jamesmunns:beeper.com> I think it's a subset of the total ram, iirc?
<re_irc>
<@jamesmunns:beeper.com> like 32KiB cacheable, xxKiB noncacheable?
<re_irc>
<@romancardenas:matrix.org> I guess, but I'd neet to go through the docs to be sure
<re_irc>
<@jamesmunns:beeper.com> if that is correct, the only way you can really soundly handle it is to TRY and keep statics + your stack in "normal" ram, and only use the other ram for stuff like large (non atomic) buffers
<re_irc>
<@grantm11235:matrix.org> > The E31 core supports the RISC-V standard Atomic (A) extension on the DTIM and the peripheral
<re_irc>
> access exception precisely at the core.
<re_irc>
> memory region. Atomic memory operations to regions that do not support them generate an
<re_irc>
> The load-reserved and store-conditional instructions are only supported on cached regions, hence
<re_irc>
> generate an access exception on DTIM and other uncached memory regions.
<re_irc>
<@jamesmunns:beeper.com> what atomics ARE there other than LR/SC?
<re_irc>
<@romancardenas:matrix.org> There are a few of amoxx operation in the ISA, maybe they refer to those
<re_irc>
<@mabez:matrix.org> : I'm guessing they're referring to just straight load/stores? Pretty big cop out though
<re_irc>
<@romancardenas:matrix.org> There are a few of amoxx operation in the ISA, maybe they refer to those
<re_irc>
<@jamesmunns:beeper.com> oh yeah, there are the AMO ones
<re_irc>
<@jamesmunns:beeper.com> it would be interesting to write some asm and see if the AMO ones succeed or not
<re_irc>
<@romancardenas:matrix.org> I'll do
<re_irc>
<@romancardenas:matrix.org> But this E31 atomic supports feels a bit lik a scam
<re_irc>
<@grantm11235:matrix.org> : the screenshot you posted from the FE310-G002 manual shows that none of the regions are cachable _and_ writable
<re_irc>
<@jamesmunns:beeper.com> yeah
<re_irc>
<@romancardenas:matrix.org> Lol
<re_irc>
<@grantm11235:matrix.org> How many variations of the chip are there?
<re_irc>
<@jamesmunns:beeper.com> which, I guess sorta makes sense? I don't totally grok what they mean be "cacheable" here, other than for like QSPI, which will get "swapped in" to ram as cache
<re_irc>
<@romancardenas:matrix.org> I'm using the E310g002, and I think there is no g003 (at least I didn't find any evaluation board with it)
<re_irc>
<@romancardenas:matrix.org> No idea about other variations
<re_irc>
<@jamesmunns:beeper.com> is there a way to make llvm/clang spit out all the target options for a given target?
<re_irc>
<@jamesmunns:beeper.com> I wonder if someone has already written a "no lr/sc amo only" flag
<re_irc>
<@mabez:matrix.org> : It would be really really strange if they implemented AMOs but not sc/lr, AFAIK you have the option in silicon to implement AMO as sc/lr but also the option to add custom silicon to do the job too 🤔
<re_irc>
<@jamesmunns:beeper.com> We provided fetch-and-op style atomic primitives as they scale to highly parallel systems better than LR/SC or CAS. A simple microarchitecture can implement AMOs using the LR/SC primitives, provided the implementation can guarantee the AMO eventually completes. More complex implementations might also implement AMOs at memory controllers, and can optimize away fetching the original value when the destination is x0.
<re_irc>
The set of AMOs was chosen to support the C11/C++11 atomic memory operations efficiently, and also to support parallel reductions in memory. Another use of AMOs is to provide atomic updates to memory-mapped device registers (e.g., setting, clearing, or toggling bits) in the I/O space.
<re_irc>
<@jamesmunns:beeper.com> ah no, that says "do it on top of lr/sc"
<re_irc>
<@dirbaio:matrix.org> oh wtf TIL about AMOs
<re_irc>
<@dirbaio:matrix.org> so it's not only LR/SC??
<re_irc>
<@dirbaio:matrix.org> riscv has x86-style "LOCK ADD blahblah"?? 😭
<re_irc>
<@dirbaio:matrix.org> iiiiiiinteresting
<re_irc>
<@jamesmunns:beeper.com> "LR/SC but only for peripherals" is certainly a choice
<re_irc>
<@jamesmunns:beeper.com> > The E31 core supports the RISC-V standard Atomic (A) extension on the DTIM and the Peripheral Port. Atomic memory operations to regions that do not support them generate an access exception precisely at the core.
<re_irc>
> The load-reserved and store-conditional instructions are only supported on cached regions, hence generate an access exception on DTIM and other uncached memory regions
<re_irc>
Still feels contradictory to me
<re_irc>
<@romancardenas:matrix.org> : I'll research on this, hopefully it exists
<re_irc>
<@grantm11235:matrix.org> Which peripherals support it? I don't see any according to the memory map
<re_irc>
<@jamesmunns:beeper.com> Yeah, I dunno, there's a lot marked as "atomic" on that map, but maybe it's only amo? that's a guess tho
<re_irc>
<@grantm11235:matrix.org> Oh wait, I was looking at the "C" label, not the "A" label
<re_irc>
<@jamesmunns:beeper.com> well, it seems to support LR/SC it has to be C+A?
<re_irc>
<@jamesmunns:beeper.com> (which is none of the regions lol)
<re_irc>
<@romancardenas:matrix.org> I think so
<re_irc>
<@romancardenas:matrix.org> : Great!
<re_irc>
<@romancardenas:matrix.org> When debugging, there were some amoxxx inthr assembly code, but the exception occured with ld and sc instructions
<re_irc>
<@dirbaio:matrix.org> > only supported in cached regions
<re_irc>
🤪
<re_irc>
<@romancardenas:matrix.org> Thank you very much, folks, at least I can sleep without atomic nightmares...
<re_irc>
<@romancardenas:matrix.org> I'll open issues in e310x stuff to kick the a out of the target
<re_irc>
<@grantm11235:matrix.org> Don't you need to pass some sort of certification to advertise your chip as being riscv?
<re_irc>
<@dirbaio:matrix.org> I don't think so?
<re_irc>
<@dirbaio:matrix.org> that's the whole point of riscv, zero gatekeeping :D
<re_irc>
<@mabez:matrix.org> : Not that I'm aware of, but I don't think gaming the system will do you any favours, saying you support something but actually don't is one way to piss people off :D
<re_irc>
<@romancardenas:matrix.org> Yep, I'm not planning to keep working with sifive stuff if I have other options
<re_irc>
<@romancardenas:matrix.org> Anyway... It is what it is
<re_irc>
<@romancardenas:matrix.org> Thanks again, I really appreciate your time
<re_irc>
<@dirbaio:matrix.org> I wonder why do this. if the e310 is supposed to be a showcase of their IP...
<re_irc>
<@dirbaio:matrix.org> they'd surely want people to see it's great
<re_irc>
<@grantm11235:matrix.org> And isn't the point of lr/sc that it is super cheap to implement? You just need a single bit that you set on lr and clear on sc or when an interrupt fires
<re_irc>
<@grantm11235:matrix.org> At least on single core anyway
<re_irc>
<@grantm11235:matrix.org> Hmm, that wouldn't work with dma though
dc740 has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> Wait, does the FE310 even have dma?
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@romancardenas:matrix.org> Don't think so
<re_irc>
<@dirbaio:matrix.org> : yea that's how atomics are implemented in cortex-m. and yeah they don't work with DMA
<cr1901>
why wouldn't it work with DMA?
<re_irc>
<@dirbaio:matrix.org> it would allow, say, an atomic increment to race with a dma write
<cr1901>
I don't follow. Why are you DMAing to the address where an atomic var exists in the first place? And why isn't the atomic increment finished before DMA begins?
<cr1901>
(unless it's transparent DMA)
<re_irc>
<@dirbaio:matrix.org> yeah it's a cursed thing to do
<re_irc>
<@dirbaio:matrix.org> so nobody does it, so it's fine that it doesn't work
<re_irc>
<@dirbaio:matrix.org> if you try to do it you deserve the pain it'll bring you
<re_irc>
<@whitequark:matrix.org> i have a hilight on "cursed" and it never fails to deliver
<cr1901>
Also ignore my remark about "transparent DMA" and "why isn't the atomic increment finished". It doesn't matter; DMA overwriting would be a race regardless of whether the var is atomic or not
<cr1901>
it's just that it's more egregious if the var's atomic :P
<cr1901>
(For that matter, why doesn't DMA cause the next SC to fail?)
<re_irc>
<@dirbaio:matrix.org> because that "LR/SC bit" is within the core
<re_irc>
<@dirbaio:matrix.org> the core has no idea that DMA went and wrote to that addr
<re_irc>
<@dirbaio:matrix.org> at least for single-core that's how I _think_ it works
<re_irc>
<@dirbaio:matrix.org> no idea about multicore
<cr1901>
"Feels" like there should be a "DMA has occurred" control signal going to the core, but, hey, Idk. I agree w/ you that if you try to DMA to the memory cell holding an atomic, you get what you deserve :P.
<re_irc>
<@thalesfragoso:matrix.org> cr1901: They don't usually mark memory regions on single core, it's just a global flag, so if they did that you wouldn't be able to do CAS on any memory if a DMA was running.
<cr1901>
By "CAS" I assume you mean "one constructed out of LR/SC", right? Why is that bad if DMA doesn't allow CAS to continue? It's not like CAS is wait-free anyway
dc740 has quit [Remote host closed the connection]
<re_irc>
<@dirbaio:matrix.org> it would destroy CAS perf or even make it hang forever if you've got lots of DMA going on
<re_irc>
<@grantm11235:matrix.org> Any dma write would need to clear the exclusivity bit
<re_irc>
<@thalesfragoso:matrix.org> cr1901: Well, it's quite common to have application where a DMA is constantly running
<cr1901>
Wouldn't interrupts always cause LR/SC to fail/deadlock if interrupts fire fast enough and all you had was a single bit of state?
<cr1901>
(Set on LR, clear on SC or interrupt)
<re_irc>
<@grantm11235:matrix.org> If your CAS loop takes longer than the time between interrupts, yeah
<re_irc>
<@thalesfragoso:matrix.org> cr1901: That's exactly what would happen, but interrupts firing fast enough is already not letting your code run nicely anyways
<cr1901>
Unfortunately, the Resetting Monitors link doesn't work anymore, but I remember reading that ARM doesn't auto-fail LL/SC if an interrupt occurs (source: trust me bro)
<re_irc>
<@thalesfragoso:matrix.org> cr1901: It's implementation specific
<re_irc>
<@thalesfragoso:matrix.org> Most implementations on single core just don't bother
<cr1901>
But it doesn't appear to mandate forward progress in the "interrupts firing too quickly on single core" case :P
<cr1901>
I guess ARM (and most ppl here) file that under "well, don't do that!" :D
<re_irc>
<@grantm11235:matrix.org> The risc-v spec also has some forward progress guarantees
<cr1901>
"same cache line, 16 bytes, subset of I insns"
<re_irc>
<@grantm11235:matrix.org> I've only skimmed it so far, but it looks interesting
<cr1901>
If you get a cache invalidation and you meet those requirements, you're allowed to ignore the cache invalidation until you get to the end of the cache line
<cr1901>
Or well, that's what I remember reading on "how to implement forward progress"