volatile keyword — preventing optimization of hardware registers: Worked examples

5.1.33 · D3 · Coding › C Programming › volatile keyword — preventing optimization of hardware regis

Yeh page parent topic se belong karti hai. Yahan hum explain karna band karke karna shuru karte hain. Hum theory lenge aur use har tarah ki situation mein run karenge jahan volatile keyword aa sakta hai — har wo optimization jo yeh disable karta hai, har pointer placement, degenerate cases (loops jo hang ho jaate hain, reads jo gayab ho jaate hain), limiting cases (-O0 vs -O2), ek real-world hardware problem, aur ek exam trap.

Kisi bhi example se pehle, do words jinhe hum har jagah use karenge — abhi define karte hain, pehli baar use karne par, taaki kuch assume na ho:

Ek aur promise: hum assume nahi karte ki aapko koi symbol yaad hai. Jab aap assembly mein [flag] dekhte hain toh iska matlab hai "memory slot jiska naam flag hai", aur R ka matlab hai "CPU register — processor ke andar ek chhota scratchpad jise woh RAM se kahin zyada tez padh sakta hai". Ek register ek memory location se alag hai; poori volatile ki kahani yeh hai ki compiler secretly memory ko ek register mein copy karta hai aur phir copy par bharosa karta hai. Woh picture yaad rakho:

Figure — volatile keyword — preventing optimization of hardware registers

Figure s01 — "Memory sachchi hai, register ek copy hai." Left mein, ek burnt-orange box hai RAM, asli slot [flag]. Right mein, ek teal box hai CPU register R, ek fast copy. Ek plum arrow "load (copy once)" dikhata hai compiler ka RAM ko register mein ek baar copy karna — yeh ek optimization hai. Dark return arrow "volatile: re-read" dikhata hai volatile kya force karta hai: har access par orange box par wapas jaao. Pedagogy: agar aap is page par sirf ek image yaad rakh sako, toh woh yaad rakho ki optimization teal copy par trust karta hai, aur volatile kehta hai copy ek jhooth hai.

The scenario matrix

Neeche har cell ek alag cheez hai jo galat ya sahi ho sakti hai. Jo examples follow karte hain woh cell(s) ke saath labelled hain jo woh cover karte hain.

#	Case class	Concrete trigger	Covered by
A	Register-caching in a spin loop	ISR sets a flag	Ex 1
B	Dead-store elimination	write-only hardware register	Ex 2
C	Duplicate-read removal	two FIFO reads collapsed to one	Ex 3
D	Reordering across accesses	data written before "go" bit	Ex 4
E	Pointer placement — data volatile	`volatile int *p`	Ex 5
F	Pointer placement — pointer volatile	`int * volatile p` (the wrong slot)	Ex 5
G	`const volatile` — read-only register	poll a status register you must not write	Ex 6
H	The `-O0` vs `-O2` limiting case	same bug appears/disappears with flags	Ex 7
I	Degenerate: volatile does not give atomicity	`count++` from an ISR	Ex 8
J	Real-world word problem	debounced button + timer tick	Ex 9
K	Exam-style twist	how many memory reads does this line emit?	Ex 10

Links jo aap padhte waqt khule rakhna chahein: Memory-mapped IO, Interrupt Service Routines (ISR), Compiler Optimization Levels (-O0 -O2), const qualifier, Atomic operations and _Atomic, Memory Barriers and Ordering, Pointers and Type Qualifiers.

Example 1 — Cell A: woh spin loop jo hang ho jaata hai

Worked example Statement

int ready = 0;                 // set to 1 by a timer ISR (Interrupt Service Routine)
void wait(void) {
    while (ready == 0) { }      // spin until hardware is done
}

Ek interrupt ready = 1 likhhta hai 5 ms baad. Kya wait() -O2 par kabhi return karega?

Forecast: padhne se pehle guess karo — kya yeh return karega, hang hoga, ya "sometimes"?

Answer: yeh hang hoga. Yahan reason hai, step by step.

Kya: compiler ready ko loop se pehle ek baar ek register mein read karta hai. Yeh step kyun? Loop body ke andar kuch bhi jo compiler dekh sakta hai ready nahi likhta. C standard ke under woh tab assume karne ki permission hai ki value stable hai, isliye ise ek fast register mein cache karna ek legal speed win hai.
Kya: woh loop ko "register ko 0 se compare karo, agar equal ho toh wapas jump karo" mein badal deta hai. Yeh step kyun? Value register mein pin hone ke baad RAM touch karne ki koi wajah nahi — woh kisi visible benefit ke bina slower hoga.
Kya: ISR (timer ka interrupt handler) memory slot [ready] likhta hai, register ko nahi. Yeh step kyun? ISR optimizer ke single-function view ke liye invisible hai; yeh is translation unit ke control flow ke bahar rehta hai. Toh memory change hoti hai lekin register nahi. Compare hamesha ke liye stale register use karta hai.

Pseudo-assembly jo optimizer emit karta hai:

    load R, [ready]     ; ONE read
L:  cmp  R, 0
    jeq  L              ; R is frozen -> forever

Fix ek word hai:

volatile int ready = 0;

jo har iteration mein loop ke andar ek asli load R, [ready] force karta hai, taaki ISR ki write dekhi ja sake.

Recall Verify (sanity check)

ISR run hone ke baad, ready ki memory value 1 hai. Ek volatile read exactly wahi return karta hai jo memory mein hai, isliye loop condition ready == 0 ban jaati hai 1 == 0 → false → loop exit. Non-volatile version frozen 0 return karta rehta hai, isliye 0 == 0 true rehta hai. Dono behaviours verification block mein recompute kiye gaye hain.

Example 2 — Cell B: woh write jo delete ho jaati hai

Worked example Statement

Ek watchdog ko uske register mein ek magic value likhke peta jaata hai:

uint32_t *WDT = (uint32_t *)0x40002000;
void pet(void) {
    *WDT = 0x5555;     // tell the watchdog "I'm alive"
    *WDT = 0xAAAA;     // second half of the unlock sequence
}

Function kabhi *WDT read nahi karta. Optimizer kya karta hai?

Forecast: kya woh dono writes rakhta hai, ek write, ya zero writes?

Kya: optimizer dekhta hai ek hi address par do stores, beech mein koi read nahi, aur value baad mein kabhi read nahi hoti. Yeh step kyun? Yeh hai dead-store elimination: agar koi value likhne ka koi observable effect nahi hai, toh write dead hai aur use remove kiya ja sakta hai. Pehla store ek clear candidate hai — bilkul agli line same address overwrite karti hai.
Kya: woh pehla store (0x5555) delete karta hai. Yeh step kyun? Ek store "dead" hai agar koi read hone se pehle same address par baad mein store hoti hai. Yahan *WDT = 0xAAAA, *WDT = 0x5555 ko overwrite karta hai beech mein kuch read hue bina, isliye compiler sure hai ki koi bhi 0x5555 observe nahi kar sakta — yeh provably wasted work hai aur remove ho jaata hai.
Kya: phir woh doosra store (0xAAAA) bhi delete karta hai. Yeh step kyun? Pehla store remove karne ke baad, function mein ek store reh jaata hai ek aise address par jo compiler ke view mein kabhi read nahi hota. Ek write jiska value koi kabhi read nahi karta woh bhi same rule se dead hai, isliye final write gayab ho jaata hai aur pet() ek empty function ban jaati hai. Watchdog ko uska unlock sequence kabhi nahi milta → chip reset. Bug.
Fix:
```
volatile uint32_t *WDT = (volatile uint32_t *)0x40002000;
```
Ab har *WDT = ... ek observable side effect hai; standard use remove karna forbid karta hai. Dono writes, order mein, memory-mapped register tak pahunch jaati hain.

Verify: store instructions count karo. Non-volatile → 0 ya 1 hardware tak pahunchte hain (collapsed case mein ≤1). Volatile → exactly 2, likhe gaye order mein. Count 2 verification block mein confirm hai.

Example 3 — Cell C: woh doosri read jo gayab ho jaati hai

Worked example Statement

Ek receive FIFO (First-In-First-Out queue: padhne se front word pop hota hai aur agla reveal hota hai) aapko ek read mein ek word deta hai:

uint32_t *DATA = (uint32_t *)0x40000010;
uint32_t a = *DATA;    // pops word #1
uint32_t b = *DATA;    // pops word #2

volatile ke bina, actually kitne words pop hote hain?

Forecast: 2 words, ya 1?

Kya: compiler notice karta hai same address ke do reads, beech mein koi write nahi. Yeh step kyun? Common-subexpression / redundant-load elimination: do identical loads "zaroor" same value denge, isliye woh a ek baar compute karta hai aur b = a set karta hai.
Kya: doosra load [DATA] remove ho jaata hai; FIFO sirf ek baar pop hoti hai. Yeh step kyun? Ek ordinary variable ke liye yeh correct aur free hai. FIFO ke liye, padhna ek side effect hai (queue advance hoti hai) — toh aap silently word #2 drop kar dete ho. Data-loss bug.
Fix: volatile uint32_t *DATA har *DATA ko ek distinct observable read banata hai; dono pops hoti hain.

Verify: volatile 2 loads emit karta hai; non-volatile 1. Dono counts verification block mein confirm hain.

Example 4 — Cell D: reordering ek protocol tod deta hai

Worked example Statement

Ek device chahta hai: pehle payload, phir "go" bit.

volatile uint32_t *PAYLOAD = (volatile uint32_t *)0x40000020;
volatile uint32_t *GO      = (volatile uint32_t *)0x40000024;
*PAYLOAD = 0x1234;   // (1) store the data
*GO      = 1;        // (2) then fire

Kya (1) aur (2) us order mein hardware tak pahunchna guaranteed hai?

Forecast: haan kyunki dono volatile hain? Careful.

Kya: kyunki dono accesses volatile hain, compiler unhe rakhna aur unhe ek doosre ke relative reorder nahi karna must hai. Yeh step kyun? C standard volatile accesses ko aapas mein order karta hai — volatile writes observable side effects hain aur doosre volatile accesses ke respect mein program order mein appear karne chahiye.
Kya (the trap): yeh ordering guarantee sirf doosre volatile accesses ke against hai. Nearby ek non-volatile store phir bhi float around kar sakta hai, aur CPU/bus hardware runtime par reorder kar sakta hai. Yeh step kyun? volatile compiler ko constrain karta hai, processor ke write buffers ko nahi. Memory system mein sach mein hardware ordering ke liye aapko ek memory barrier bhi chahiye — concretely Example 4b mein dikhaya gaya hai.
Takeaway: volatile-to-volatile order compiler ke liye preserved hai; agar aap ordinary variables mix karte ho ya cross-core/hardware ordering chahiye, toh barrier add karo.

Verify: pair (PAYLOAD then GO) do volatile accesses ke liye source order mein rehta hai — verification block mein ek order property ke roop mein confirm hai.

Example 4b — woh barrier jo actually order enforce karta hai

Worked example Statement

Processor ka ek write buffer hai: compiler ke stores order mein emit karne ke baad bhi, hardware *GO ko bus tak pahunchne de sakta hai *PAYLOAD land hone se pehle. Ek memory barrier ek special CPU instruction hai jo kehta hai "mere se pehle sab kuch mere baad kuch bhi hone se pehle complete hona chahiye". C mein hum ise aisa insert karte hain:

#include <stdatomic.h>
*PAYLOAD = 0x1234;                       // (1) store the data
atomic_thread_fence(memory_order_release); // BARRIER: (1) must land first
*GO      = 1;                            // (2) fire, guaranteed after (1)

Kai embedded chips par wahi idea ek raw instruction hai, jaise ARM __DMB() (Data Memory Barrier).

Kya: volatile dono writes rakhta hai aur unka compiler order rakhta hai. Yeh step kyun? volatile ke bina, compiler unhe hardware tak pahunchne se pehle delete ya reorder kar sakta tha — barrier akela humein save nahi karta.
Kya: barrier (atomic_thread_fence / __DMB()) hardware ko force karta hai go write se pehle payload write drain karne ke liye. Yeh step kyun? Barrier guarantee ka runtime half hai; volatile compile-time half hai. Ek correct device protocol ke liye aapko aksar dono chahiye. Dekho Memory Barriers and Ordering.

Figure s02 — "volatile compiler ko order karta hai; barrier hardware ko order karta hai." Top track (teal) compiler ka output hai: store PAYLOAD phir store GO, volatile se order mein rakha gaya. Bottom track (orange) hardware write buffer hai: barrier ke bina dono stores swap ho sakte hain (dashed crossing arrows, plum "reorder?"); vertical plum bar labelled "memory barrier" us crossing ko block karta hai taaki GO sirf PAYLOAD ke baad nikal sake. Pedagogy: do alag actors reorder karte hain — compiler aur CPU — aur aapko har ek ke liye ek tool chahiye.

Verify: barrier ke saath, hardware-visible order hai PAYLOAD before GO (slot index mein difference positive) — verification block mein confirm hai.

Example 5 — Cells E & F: right-to-left pointer parsing

Declarations ko right-to-left padho, exactly jaise aap arctan ko angle se peel karte ho — aap pehle outer question strip karte ho.

Figure s03 — "Right-to-left batata hai kaunsa part volatile hai." Top row dikhata hai volatile int *p: ek teal box "p = pointer" aur ek orange box "*p target = VOLATILE", ek arrow ke saath "correct for registers" — data re-read hota hai. Bottom row dikhata hai int * volatile p: ek plum box "p = VOLATILE ptr" aur ek dark box "*p target = plain", ek arrow ke saath "*p still cached -> wrong" — sirf pointer variable protected hai. Pedagogy: word volatile usi cheez se bind hota hai jiske bilkul saath mein woh baitha hai; right-to-left padhna us binding ko visible banata hai.

volatile int *p (E): right-to-left peel karo → "p ek pointer hai volatile int ki taraf". Pointed-at cheez volatile hai, isliye *p har baar re-read hota hai. Yeh woh hai jo registers ko chahiye. Yeh step kyun? Ek register us address par rehta hai jo p hold karta hai; aap chahte ho ki us address par data phir se fetch ho, address variable itself nahi.
int * volatile p (F): right-to-left peel karo → "p ek volatile pointer hai ek plain int ki taraf". Yahan volatile pointer variable p ke paas baitha hai, isliye pointer memory se re-read hota hai; target *p ek ordinary int hai aur phir bhi register mein cached ho sakta hai. Yeh step kyun? volatile usi cheez se bind hota hai jiske saath woh khada hai. Form F mein woh p ke saath khada hai, isliye compiler address value protect karta hai, data ko nahi us address par. Ek hardware register ke liye yeh galat cheez protect karna hai: saari baat yeh hai ki register ka content aapke neeche change ho jaata hai, phir bhi form F compiler ko allow karta hai *p ek baar padhne aur stale copy reuse karne ki. Yeh cleanly compile hoti hai aur kuch useful nahi karta — classic silent mistake.
Jab zarurat ho combine karo: volatile int * volatile p = dono pointer aur uska target volatile hain (rare; jab pointer itself volatile memory mein ho tab use hota hai).

Verify: parse rules structural hain — verification block mein "which of {pointer, target} is volatile" encode karke har form ke liye confirm kiye gaye hain.

Example 6 — Cell G: `const volatile`, read-only register

Worked example Statement

Ek status register: hardware ise update karta hai, lekin aapka firmware use kabhi nahi likhna chahiye.

const volatile uint32_t *STATUS = (const volatile uint32_t *)0x40004000;
while (!(*STATUS & 0x01)) { }   // wait for "ready" bit

Kya const volatile ek contradiction hai?

Forecast: legal hai, ya compiler error?

Kya: const kehta hai "mera code is pointer ke through nahi likhega" — ek write attempt compile error hai, bugs pakadta hai. Yeh step kyun? Dekho const qualifier: const ek promise hai jo aapka program karta hai, physical bits ke baare mein koi claim nahi.
Kya: volatile kehta hai "koi aur (hardware) ise change karta hai, isliye har access par re-read karo". Yeh step kyun? Dono qualifiers alag actors describe karte hain. Koi contradiction nahi: aapke liye read-only, bahar se changing.
Kya: *STATUS & 0x01 sirf bit 0 (lowest bit) rakhta hai aur baaki zero kar deta hai, 0 ya 1 deta hai. Yeh step kyun? Doosre bits unrelated flags ho sakte hain; sirf bit 0 rakhna "ready" signal isolate karta hai taaki loop condition exactly ek cheez test kare.

Verify: STATUS value 0x04 ke liye (bit 0 clear) loop rehta hai; 0x05 ke liye (bit 0 set) exit hota hai. 0x04 & 0x01 = 0 aur 0x05 & 0x01 = 1 — verification block mein confirm hai.

Example 7 — Cell H: same bug `-O0` aur `-O2` par

-O0 par kya hota hai: `-O0` almost koi optimization nahi karta, isliye woh happen to har iteration mein [ready] re-read karta hai. Bug accident se chhup jaata hai. Yeh step kyun? -O0 naive memory accesses rakhta hai debugging predictable banane ke liye; re-read laziness ka side effect hai, guarantee nahi.
-O2 par kya hota hai: Example 1 ka register-caching kick in karta hai → infinite loop. Yeh step kyun? -O2 cache karne ki permission hai kyunki non-volatile variable ne use bataya "koi aur mujhe change nahi karta". Code ne jhooth bola; compiler ne believe kiya.
Verdict: code galat hai (missing volatile), compiler nahi. volatile se fix karne par yeh har -O level par correct ho jaata hai.

Verify: correctness flag par depend nahi karni chahiye — verification block mein "volatile ⇒ caching se regardless same observed value" ke roop mein confirm hai.

Example 8 — Cell I: volatile atomic nahi hai

Kya: count++ teen steps mein compile hota hai: load → add 1 → store. Yeh step kyun? Memory increment karna inherently read-modify-write hai; CPU zyaatar architectures par "+1 in place" ek indivisible action ke roop mein nahi kar sakta.
Kya: ek interrupt load aur store ke beech fire kar sakta hai. ISR aur main dono same old value load kar sakte hain, dono 1 add karte hain, dono store karte hain — aap ek increment khote ho. Yeh step kyun? volatile guarantee karta hai ki har load/store memory hit kare, lekin yeh teen steps ko ek uninterruptible atomic operation mein fuse nahi karta, aur koi memory barrier add nahi karta.
Fix: `_Atomic int` / `atomic_fetch_add` use karo ya update ke around interrupts disable karo.

Numeric picture — do +1s jo race karte hain +1 total produce kar sakte hain:

main: load 5          ISR: load 5
main: add  -> 6       ISR: add  -> 6
main: store 6         ISR: store 6      // final = 6, not 7

Verify: 5 se do atomic increments ka expected result 7 hai; lost-update race 6 deta hai. Dono verification block mein confirm hain.

Example 9 — Cell J: real-world word problem (button + tick)

Worked example Statement

Ek timer ISR (interrupt handler jo har 1 ms run hoti hai) volatile uint32_t ticks increment karta hai. Main code ek button debounce karta hai: use 20 ms tak continuously "pressed" read karna confirm karna hoga believe karne se pehle. Wait sketch karo aur batao ki har variable ka qualifier kyun matter karta hai.

volatile uint32_t ticks;                    // ISR: ticks++ each ms
#define BTN (*(volatile uint8_t *)0x40006000) // hardware input port
 
int debounced_press(void) {
    if (!(BTN & 0x01)) return 0;            // not pressed now (keep bit 0)
    uint32_t start = ticks;                 // snapshot the clock
    while ((ticks - start) < 20) {          // wait up to 20 ms
        if (!(BTN & 0x01)) return 0;        // released early -> bounce
    }
    return 1;                               // held 20 ms -> real press
}

Forecast: kaun se do variables logic tod denge agar unka volatile chala jaaye?

Kya: ticks zaroor volatile hona chahiye. Yeh step kyun? Loop condition ticks - start depend karta hai ticks ke ISR se change hone par. Volatile ke bina compiler ticks cache karta hai, isliye ticks - start hamesha 0 < 20 rehta hai → hang.
Kya: BTN zaroor volatile hona chahiye. Yeh step kyun? Yeh ek memory-mapped input hai jo hardware update karta hai. Non-volatile pin ko ek baar read karta aur koi release notice nahi karta → debouncing defeat ho jaati. (BTN & 0x01 sirf bit 0 rakhta hai, pressed/released bit.)
Kya: start ek ordinary local hai. Yeh step kyun? Ek volatile read se ek baar likha jaata hai aur kisi aur ne change nahi kiya — ise volatile banane ki koi wajah nahi.
Numeric check: agar button held hai aur ticks runs start, start+1, … , start+20, loop exit hota hai jab ticks - start pehli baar 20 reach karta hai (20 ms). Agar start+7 par release ho, difference 7 < 20 still true hai isliye hum loop ke andar hain, lekin BTN test 0 return karta hai — ek rejected bounce.

Verify: exit condition (ticks - start) < 20 difference 20 par false ho jaati hai; 20 - 0 = 20 aur 7 < 20 true hai (still waiting) — dono verification block mein confirm hain.

Example 10 — Cell K: exam-style twist ("reads count karo")

Worked example Statement

Diya gaya

volatile int v;
int n;
int r = v + v + n + n;   // v aur n ki kitni REAL memory reads?

-O2 par. v aur n ke liye count batao.

Forecast: padhne se pehle do numbers likh lo.

v ke liye kya: ek volatile object ki expression mein har occurrence ek alag observable read hai. v + v v ko do baar read karta hai. Yeh step kyun? Standard har volatile access ko side effect maanta hai; compiler dono ko ek mein merge nahi kar sakta chahe woh identical lagte hon.
n ke liye kya: n ordinary hai. n + n ek read mein collapse ho sakta hai, phir 2*n, ya aur fold ho sakta hai. Yeh step kyun? Koi side effect na hone se, redundant-load elimination compiler ko n ek baar read karne deta hai (count 1).
Answer: v → 2 reads (mandatory); n → 1 read (optimized).

Verify: v ke liye volatile-read count 2 hai; check verification block mein "2 vs 1" contrast encode karta hai.

Active recall

ISR ka matlab kya hai aur volatile ke liye kyun matter karta hai?

Interrupt Service Routine — ek function jo hardware khud call karta hai, visible flow ke bahar, isliye compiler nahi dekh sakta ki yeh ek variable kab change karta hai; isliye aise variables ko volatile chahiye.

FIFO kya hai aur use padhna side effect kyun hai?

Ek First-In-First-Out hardware queue jahan padhne se front word pop hota hai aur agla reveal hota hai, isliye ek read state change karta hai — compiler "duplicate" read remove nahi kar sakta.

v + v mein v ki kitni real reads hoti hain jab v volatile hai?

Do — har volatile access ek alag observable side effect hai aur merge nahi ki ja sakti.

Example 8 ka race 5 ko do baar increment karne par 7 ki jagah 6 kyun deta hai?

Dono increments same old value 5 load karte hain, 1 add karke 6 karte hain, aur 6 store karte hain; ek update lost ho jaata hai kyunki count++ atomic nahi hai.

debounced_press mein, button held hone par wait loop kab exit karta hai?

Jab ticks - start pehli baar 20 ke barabar ho, yaani 20 timer ticks (20 ms) ke baad.

STATUS value 0x04 ke liye, kya while(!(*STATUS & 1)) wait karta rehega?

Haan — 0x04 & 0x01 = 0, isliye !0 true hai aur loop spinning karta rehta hai.

Kaun se do tools milke guarantee karte hain ki device PAYLOAD se pehle GO dekhe?

volatile (compiler ko stores remove/reorder karne se rokta hai) plus ek memory barrier (CPU write buffer ko unhe runtime par reorder karne se rokta hai).