Pre-RFC: Conditionally-supported volatile access to address 0

Rust adopts the C++ memory model, yes. But that model says nothing about volatile accesses -- they are non-atomic and thus race conditions on them are UB.

Yes, in fact they do. It's called compiler-optimization barriers. I make use of atomic operations on the 65816 to communicate with interrupt handlers, which I treat as separate threads of execution, rather than signal handlers to make it easier to reason about them. With small enough atomics, I do nothing special at runtime, but still tell the compiler to impose the same ordering rules. This prevents an aggressively optimizing compiler from breaking code that needs to talk to interrupts.

If I have a volatile access followed by a release operation, an acquire operation which the release happens-before will be able to observe the volatile access, strictly because of the semantics of the memory access, not because of its volatility. However, I'm unsure that it can be proven the same way that inline assembly will happen-before the release operation. All accesses to scalar objects sequenced-before an atomic release operation strongly happen-before that operation, and the access being volatile doesn't change that property.

The 65816, AKA WDC 65C816, is a 37-year-old enhanced variant of a 6502, which explains its legacy use of 0x0…0 as a valid address. Your use of modern atomics to restrict compiler code motion makes sense, even if atomics per se weren't something that the original 6502 designers ever considered.

an additional architecture that stores valid data at address 0 is real mode x86 (e.g. DOS), it stores the interrupt vector table at address 0. IIRC, real mode is still used to boot nearly every x86/AMD64 computer in existence.

Skimming a few of the ARMv*-M architecture reference manuals they all seem to allow reading from address 0. These are very relevant to embedded work with Rust. I tried checking ARMv8-A (aka aarch64) as well, but that’s a much more complicated manual :sweat_smile: (it seems likely that OSs map an inaccessible page at address 0, but kernel level code may have access).

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.