ello_ has quit [Read error: Connection reset by peer]
ello_ has joined #rust-embedded
sroemer has joined #rust-embedded
glitchy has quit [Ping timeout: 272 seconds]
glitchy has joined #rust-embedded
bandini has joined #rust-embedded
seds has quit [Ping timeout: 272 seconds]
nprice has quit [Ping timeout: 272 seconds]
NishanthMenon has quit [Ping timeout: 264 seconds]
seds has joined #rust-embedded
nprice has joined #rust-embedded
NishanthMenon has joined #rust-embedded
inara has quit [Ping timeout: 265 seconds]
inara has joined #rust-embedded
leftger[m] has quit [Quit: Idle timeout reached: 172800s]
szymon[m] has quit [Quit: Idle timeout reached: 172800s]
raymondr has joined #rust-embedded
Lumpio[m] has joined #rust-embedded
<Lumpio[m]>
<dirbaio[m]> it's a core operation underpinning CIDR routing
<Lumpio[m]>
I've always seen that as a bunch of bitwise operations rather than addition
<dirbaio[m]>
Lumpio[m]: Using addition better optimizes the flux capacitance of the internetworks
<Lumpio[m]>
Uh-huh
<dirbaio[m]>
🤣
az1[m] has quit [Quit: Idle timeout reached: 172800s]
gkoebel has joined #rust-embedded
gkoebel has quit [Client Quit]
gkoebel has joined #rust-embedded
gkoebel has quit [Changing host]
gkoebel has joined #rust-embedded
gkoebel has quit [Remote host closed the connection]
gkoebel has joined #rust-embedded
gkoebel has quit [Changing host]
gkoebel has joined #rust-embedded
davidmpye[m] has quit [Quit: Idle timeout reached: 172800s]
JamesMunns[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
raymondr has quit [Remote host closed the connection]
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
As a misc heads up, "using external psram memory that doesn't work with atomics, on an atomic target" is becoming explicitly illegal: https://github.com/rust-lang/rust/pull/158586
<diondokter[m]>
Yeah I saw. That means that you need to turn off atomics on your whole program if you use external RAM without atomic support. That kinda sucks
<diondokter[m]>
Sensible from the compiler's point of view though
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
I'm not sure it _meaningfully_ changes anything, honestly, I think it was pretty much illegal before
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
Or don't use atomics on external ram that doesn't use atomics. Given one of my use cases is shoving PCM buffers into psram its probably not an issue for me
<JamesMunns[m]>
now it's just _officially_ illegal
<JamesMunns[m]>
it was always undefined/implementation defined behavior
<diondokter[m]>
i509vcb[m]: This is now officially illegal to do. Even when you're careful
<i509vcb[m]>
diondokter[m]: Okay so no atomics then
<i509vcb[m]>
I assume there's a -C flag to stop atomics?
<i509vcb[m]>
Or is it a new target definition then?
<JamesMunns[m]>
you need to use a different target
<JamesMunns[m]>
yeah
<JamesMunns[m]>
(or, a custom target with build-std)
<JamesMunns[m]>
since thumbv7/thumbv8 always have atomics enabled at the target level
<i509vcb[m]>
Unfortunately all the interesting parts external ram are thumb7/8
<i509vcb[m]>
No thumb6
<JamesMunns[m]>
the other alternative is "don't map the psram into address space", and treat it more like a peripheral
<JamesMunns[m]>
and do explicit read/write ops
<diondokter[m]>
Hmmm, don't specify it as a memory region, do memory map it and then only touch it through inline assembly? That should be legal too
<i509vcb[m]>
I guess DMA could do the copies for me
<JamesMunns[m]>
yeah, the big thing is "never turn it into a rust type you can dereference"
<diondokter[m]>
The reasoning why it's illegal btw is that the compiler may turn any access into an access that uses an atomic instruction
<JamesMunns[m]>
(which is a silly thing that it will basically never do, but it is allowed to do so)
<diondokter[m]>
That's what I gathered from Zulip at least
<diondokter[m]>
At least it's not the 'nasal demons' type of UB
<i509vcb[m]>
Yeah the other use is software rendering directly into ram which may be less nice in a world where you get atomics or references to external memory
sroemer has quit [Quit: WeeChat 4.7.2]
<thejpster[m]>
treating PSRAM like MMIO space should be fine
<thejpster[m]>
you cannot do atomic operations on a UART Data TX register, and no one says UART drivers are illegal
<thejpster[m]>
> The reasoning why it's illegal btw is that the compiler may turn any access into an access that uses an atomic instruction
<thejpster[m]>
I think they should just tell LLVM to promise not do that.
<thejpster[m]>
It makes writing MMU set-up code in Rust illegal, because atomic operations are UB if you don't have the cache on, and you can only have the cache on once the MMU is set up (if I remember correctly).
<thejpster[m]>
the whole "rustc/LLVM might do magic things behind your back" is a compelling reason to just stick to writing C code to be honest. I would like it to just compile the code I gave it.
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
C has the same issues if you use Clang, with a few exceptions...
<whitequark[cis]>
gcc doing (to me, at the time) insane things with bitfields in MMIO was a big motivation to find the paper that led me to then-pre-1.0 rust
<whitequark[cis]>
gcc was of course allowed to do that, as i know now
<thejpster[m]>
what I'm hearing is that all compilers are the worst, except perhaps every other compiler
DnielBuga[m] has joined #rust-embedded
<DnielBuga[m]>
<JamesMunns[m]> As a misc heads up, "using external psram memory that doesn't work with atomics, on an atomic target" is becoming explicitly illegal: https://github.com/rust-lang/rust/pull/158586
<DnielBuga[m]>
yaay
<whitequark[cis]>
inline assembly should be easier and assemblers should be better
<whitequark[cis]>
then nobody can break your cursed code
<whitequark[cis]>
unfortunately....
<thejpster[m]>
I had to write some inline asm for gcc the other day.
<thejpster[m]>
Sorry, I mean : the : other : day :
<thejpster[m]>
Well qwandor did but he works at Google, so.
<thejpster[m]>
He’s working on rusted-firmware-A.
<dngrs[m]>
ya I mean it's hosted on gh/google
<dngrs[m]>
anyway, nice stuff it seems
<thejpster[m]>
I understand that’s what happens if you work at Google and do a thing
<dngrs[m]>
ah, so it's not an official blessing, more like a side effect?
<thejpster[m]>
It’s just like derive-mmio, which I wrote at exactly the same time
<thejpster[m]>
They use a field projection macro and I generate functions
<thejpster[m]>
field!(uart, control).read()
<thejpster[m]>
vs
<thejpster[m]>
uart.read_control()
<dngrs[m]>
one difference their comparison table lists is "Works around aarch64 volatile bug"
<thejpster[m]>
dngrs[m]: That is my understanding. I may be wrong.
<thejpster[m]>
Yeah aarch64 is broken
<dngrs[m]>
oh dear
<thejpster[m]>
If you trap an IO operation into the hypervisor, a register tells you all about what the instruction was trying to do
<thejpster[m]>
But the instruction does a writeback on a register, (like, read from x0, and add 8 to x0 at the same time) the hypervisor is not told about the add 8
<thejpster[m]>
Bad things then happen
<thejpster[m]>
But LLVM loves a free addition! As a treat. And will do it on random MMIO operations.
<dngrs[m]>
oops
<thejpster[m]>
I could also fix it in derive-mmio but I don’t use a hypervisor so I haven’t bothered.
<thejpster[m]>
Also I largely stick to aarch32
<whitequark[cis]>
<thejpster[m]> But the instruction does a writeback on a register, (like, read from x0, and add 8 to x0 at the same time) the hypervisor is not told about the add 8
<whitequark[cis]>
how is this not a hypervisor bug
<whitequark[cis]>
it should read the word at PC and emulate
<whitequark[cis]>
that's how it's been done for ages
<thejpster[m]>
But that’s slow. The hardware can do the job for you.
<whitequark[cis]>
<thejpster[m]> But that’s slow. The hardware can do the job for you.
<whitequark[cis]>
it obviously cannot, given we're having this discussion
<whitequark[cis]>
(and it's not even particularly slow unless you're on x86. where this is done anyway, just look at how many disassemblers are in Linuxl