Exercises — volatile keyword — preventing optimization of hardware registers

Rule: volatile is needed only when a value can change without any visible-code action. Three sources do this:

• Hardware register — a peripheral flips bits on its own.
• ISR — an interrupt handler runs on your CPU between two of your instructions and writes the variable.
• Another thread / DMA — DMA (Direct Memory Access) is a separate hardware engine copying into RAM in parallel; a second thread runs concurrently on another core. Both change memory while your loop runs, with no visible write in your code.

The figure below shows these three "invisible writers" reaching around the compiler to the same memory cell.

Caching the value in a register. Because nothing visible writes status inside the loop, the compiler treats the load as loop-invariant — its value can't change across iterations — and applies loop-invariant code motion (LICM): it hoists the load out of the loop into a CPU register, then loops on that register copy forever.

• "Loop-invariant code motion" is the standard optimizer name; "caching in a register" is the everyday way to describe its effect here.
• (Dead-store elimination is about writes that are never read; reordering is about moving accesses — neither is the cause here.)

Make the pointed-to data volatile:

volatile uint8_t *SR = (volatile uint8_t *)0x4000C000;
while (!(*SR & 0x01)) { }

Why the target and not the pointer? We re-read *SR every loop, so the thing being read must be volatile. Parsing right-to-left: volatile uint8_t *SR = "SR is a pointer to a volatile uint8_t". See pointer qualifiers. Why & 0x01? The status register packs many flags; 0x01 masks all bits except bit 0 so we test only "data ready".

• With volatile: 3 reads. A volatile access is an observable side effect, so the compiler cannot merge them.
• Without volatile: 1 read. The compiler sees three reads of the same address with no write between and collapses them to b = a; c = a; — losing two FIFO words.

Answer: 3 with, 1 without.

const volatile uint32_t *STATUS = (const volatile uint32_t *)0x40000004;

Why both? const (from const qualifier) makes the compiler reject any *STATUS = ... in your code — a compile-time guard. volatile forces a fresh read each time because hardware mutates it. They are not opposites: const = "I won't write it", volatile = "something else does".

The figure parses the three placements graphically (read right-to-left).

(A) non-volatile — load is OUTSIDE. Walk it line by line:

    load  R, [flag]   ; ONE read, hoisted ABOVE the loop
L:  cmp   R, 0        ; compare the cached register R
    jeq   L           ; R never changes -> jump back forever

The compiler proved nothing in the loop writes flag, so the load is loop-invariant and got hoisted out. Inside the loop there is now no memory access at all — only the register R is tested. If an outside agent (ISR/hardware) writes memory, R never learns of it ⇒ hang.

(B) volatile — load is INSIDE.

L:  load  R, [flag]   ; RE-READ memory every iteration
    cmp   R, 0
    jeq   L

Because a volatile read is an observable side effect, the compiler is forbidden to hoist it. The load stays below the label L, so every trip round the loop touches real memory and sees any external write.

The one-line difference: in (A) the load is above L (executes once); in (B) it is below L (executes every iteration).

The figure below is a timeline: the same ISR write arrives at time t, but only the volatile loop has a memory read after t to notice it.

No — it is accidental, not correct.

• -O0 happens to keep the re-read only because it does not perform loop-invariant code motion (see Compiler Optimization Levels (-O0 -O2)).
• The C standard still permits caching a non-volatile variable at any level; another compiler or a future -O2 build re-breaks it.
• It also disables all optimizations everywhere, tanking performance.

Correct fix = volatile, which is right at every optimization level and documents intent.

Common-subexpression elimination / redundant-load elimination. False assumption: "a memory location's value doesn't change unless visible code writes it, so re-reading the same address gives the same result." True for RAM, false for a FIFO where the read itself has a side effect (advancing the queue).

Bug 1 — ready not volatile: the poll loop caches it → hang. Fix: volatile int ready = 0;. Bug 2 — no ordering guarantee: even with volatile, the compiler/CPU may make main see ready == 1 before the packet bytes are visible, because volatile provides no barrier across packet and ready (see Memory Barriers and Ordering). A memory barrier is a fence instruction that forces all writes before it to become visible before any write after it. Fix — insert a barrier between the payload writes and the flag, so packet is guaranteed visible first:

volatile int ready = 0;
 
// Inside the ISR:
void isr(void) {
    packet.b[0] = a;  packet.b[1] = b;
    packet.b[2] = c;  packet.b[3] = d;   // (1) write payload
    __sync_synchronize();                // (2) full memory barrier (GCC/Clang builtin)
    ready = 1;                           // (3) now publish the flag
}

The __sync_synchronize() fence guarantees steps (1) land in memory before step (3).

What is memory_order_release? The C11 model lets you attach an ordering tag to an atomic write. A release write is a one-directional fence: it guarantees that everything written before it becomes visible to any reader before that reader can see the released value. So a release-tagged write of ready bundles the "publish payload first" barrier into the flag write itself — the reader pairs it with an acquire read. Cleaner than a separate __sync_synchronize():

_Atomic int ready = 0;                              // see [[Atomic operations and _Atomic]]
atomic_store_explicit(&ready, 1, memory_order_release);   // publish payload, then flag

volatile alone fixes visibility of the flag, not ordering of the payload.

Not correct. volatile forces each access to memory, but shared_count++ is load → modify → store — three separate accesses. An interrupt firing between load and store loses an increment (a lost-update race). Fix: use `_Atomic`: _Atomic int shared_count; and atomic_fetch_add(&shared_count, 1);, or disable interrupts around the update. Slogan: volatile ⇒ fresh, not atomic.

(a) The single read pops the first word: 10. (b) Buggy: the cached 10 is added four times → sum = 10 + 10 + 10 + 10 = 40. (c) Correct (volatile forces 4 real reads popping 10, 20, 30, 40): sum = 10 + 20 + 30 + 40 = 100. (d) Only word 0 was ever read. Words 20, 30, 40 are never popped → 3 words lost, combined value 90.

Consistency check: the correct sum (100) minus the buggy sum (40) equals 60, which is not the same as the lost-words total (90) — because the bug both drops 20,30,40 and double-counts 10 three extra times. That mismatch is itself the lesson: caching corrupts the total in two ways at once.

Fix: volatile uint32_t *FIFO = (volatile uint32_t *)0x40000010;.

This is exactly a read-only hardware status register: hardware writes it (volatile ⇒ re-read), your code may only read it (const ⇒ writes rejected).

1. 2 writes. Volatile writes are observable side effects — the compiler may not drop the "dead" second store. (Non-volatile, it would emit 1.)
2. 2 reads. Both v reads hit memory (t merges are irrelevant — the reads of v count).
3. 1 read. Even a discarded volatile read is an observable side effect and must happen; a non-volatile v; would be deleted entirely.

Totals: 2, 2, 1.

No. On an 8-bit MCU a 32-bit volatile load is compiled into four separate byte reads (the data bus is only 8 bits wide — see the jargon box). The timer ISR can fire between two of those byte reads and update tick, so main can assemble a torn value: some bytes old, some new (e.g. read 0x00FF, ISR bumps to 0x0100, you finish reading and get 0x01FF — a value that never existed).

• volatile guarantees each byte access is fresh and real, but it does not make the four-byte sequence atomic.
• On a 32-bit CPU the same uint32_t moves in one bus transaction, so a single access is atomic there — this bug is width-dependent, which is exactly why it's easy to miss when porting from a 32-bit dev board to an 8-bit target.
• Fix: use `_Atomic`, or read tick twice and retry until two reads agree, or briefly disable interrupts around the read. Slogan: volatile ⇒ fresh, not atomic — and "one C statement" is not the same as "one bus transaction".