Elna

volatile marks an access whose occurrence is itself observable, either because the value can change outside the program's control or because touching the location has an effect the compiler cannot see. Elna offers it in two forms: a type qualifier, so that every access through a volatile T carries the guarantee, and the volatile_load/volatile_store intrinsics, which apply it to a single access through an ordinary pointer. In both forms the obligation is identical — the compiler emits the access exactly as written, with none elided, merged, reordered against another volatile access, or invented.

Three uses have no alternative:

• Memory-mapped I/O. A device register read is a bus transaction with an effect on the device. The compiler must not delete a read whose result is unused, merge two reads into one, hoist one out of a loop, or reorder it against another. Only volatile says this access occurs, exactly this many times, in this order.
• Signal handlers. The sole portable channel between a handler and the code it interrupts. Atomics do not help here: a handler runs on the same thread, so there is no cross-thread edge to establish — only a compiler that must not keep the value in a register across the interruption.
• Values live across a non-local jump or across any control transfer the compiler cannot see.

If a volatile aggregate is accessed, all it fields accessed separately, in declaration order without touching the padding.