Visual walkthrough — volatile keyword — preventing optimization of hardware registers

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

Hum sirf yeh maante hain ki tum jaante ho ki ek program instructions ki list hoti hai aur computer mein kuch fast scratch slots (registers) aur ek bada slow store (memory / RAM) hota hai. Baaki sab hum yahan build karenge.

Step 1 — Wo do jagah jahan ek value reh sakti hai

KYA HAI. Ek number jo tumhara program use karta hai, woh do mein se ek jagah rehta hai: memory (ek numbered mailbox, reach karne mein slow) ya ek CPU register (processor ke andar ek chhota sa slot, blazing fast). Figure dekho: daayein taraf ka mailbox [flag] memory hai; baayein taraf ka box R ek register hai.

YEH KYUN MATTER KARTA HAI. Memory tak pahunchne mein kaafi CPU cycles lagte hain. Ek register tak pahunchne mein almost kuch nahi lagta. Isliye compiler chahta hai ki memory ki value ko ek baar register mein copy kare aur phir register ko reuse kare. Woh copy hi is poore page ki kahani hai.

PICTURE.

Step 2 — Compiler ki core assumption

KYA HAI. C compiler tumhari function padhta hai aur ek mental model banata hai: "memory ko sirf wahi cheezein touch karti hain jo main yahan likhi hui dekh sakta hoon." Us belief ke saath, agar kuch bhi flag ko write nahi karta dikhtaa, toh R mein jo value hai woh [flag] ki perfect copy hamesha ke liye sahi rahegi.

KYUN. Yahi assumption har speed optimization ko allow karti hai. Agar register copy kabhi stale nahi ho sakti, toh dobara load kyun karein? Figure mein compiler R par ek green "still valid" seal lagata dikhta hai kyunki ushe loop ke load aur use ke beech koi write nahi dikhti.

PICTURE.

Step 3 — Optimization chalta hai: ek baar read

KYA HAI. Classic wait loop lo:

int flag = 0;
while (flag == 0) { }

Compiler Step 2 apply karta hai: loop mein kuch bhi flag ko write nahi karta, toh woh ek baar load karta hai, loop se pehle, aur register par spin karta hai.

KYUN. Har iteration mein dobara load karna bilkul waste hoga assumption ke anusaar. Toh optimizer load ko bahar le jaata hai. Figure mein load arrow loop box ke bahar draw hoti dikhtii hai — yeh exactly ek baar hoti hai.

PICTURE.

Jo shape generate hoti hai:

    load  R, [flag]     ; EK read, loop se pehle
L:  cmp   R, 0           ; CACHED copy compare karo
    jeq   L              ; zero ke barabar? wapas jump karo

• cmp R, 0 — register R ko number 0 se compare karo.
• jeq L — "jump if equal" wapas label L par. Kyunki R loop ke andar kabhi nahi badlata, jeq hamesha jump karta hai. Yeh sirf tabhi sahi hai jab Step 2 ki assumption hold kare.

Step 4 — Ek hidden writer assumption ko tod deta hai

KYA HAI. Ab ek real chip aata hai. Ek interrupt service routine tumhari instructions ke beech run karta hai aur memory mein likhta hai:

void timer_isr(void) { flag = 1; }   // hardware isko call karta hai

ISR [flag] = 1 memory mein likhta hai. Lekin loop R par spin kar raha hai, jo abhi bhi 0 hai. Mailbox mein jo sach tha woh badal gaya; register mein copy nahi badli.

YEH KYUN HANG KARTA HAI. Step 2 ki equation, $R=[\text{flag}]$, ab galat hai — lekin compiler ne yeh belief bake in kar li thi ki yeh kabhi galat nahi ho sakti, toh koi re-load generate nahi hua. Figure mein ISR ka coral arrow sirf mailbox tak pahunchta dikhta hai, register tak nahi. Loop deaf hai.

PICTURE.

Step 5 — volatile assumption ko delete kar deta hai

KYA HAI. Variable ko qualify karo:

volatile int flag = 0;
while (flag == 0) { }

volatile compiler ko kehta hai: "is variable ke liye, Step 2 ki assumption FORBIDDEN hai. Har read ko aise treat karo jaise koi hidden writer abhi memory badal chuka ho."

YEH EXACT CURE KYUN HAI. Bug ek specific galat belief tha — "$R$ valid rehta hai". volatile koi locks nahi add karta, poore program ko slow nahi karta, doosre variables ko touch nahi karta. Yeh surgically woh ek permission hata deta hai jisne bug produce kiya. Ab load wapas loop ke andar aa jaata hai (figure): har comparison se pehle memory ki taaza trip hoti hai.

PICTURE.

L:  load  R, [flag]     ; HAR ITERATION MEIN RE-READ
    cmp   R, 0
    jeq   L

Ab jab ISR [flag] = 1 set karta hai, agla load 1 dekhta hai, cmp fail hoti hai, jeq fall through karta hai, aur loop exit ho jaata hai. Hardware → memory → register → tumhare code ki chain of custody toot-i nahi.

Step 6 — Edge case: dead-store / duplicate-read trap

KYA HAI. Ek FIFO (first-in-first-out queue) hardware register: ise padhne se ek word consume hota hai aur agla word aata hai.

volatile uint32_t *DATA = (volatile uint32_t *)0x40000010;
uint32_t a = *DATA;   // word #1 pull karta hai
uint32_t b = *DATA;   // word #2 pull karta hai

VOLATILE YAHAN KYUN ZAROORI HAI. volatile ke bina, compiler ek hi address ki do reads dekhta hai beech mein koi write ke, maan leta hai ki dono identical hain, aur b = a likh deta hai — doosri asli read delete kar deta hai. Yeh data loss hai: word #2 kabhi nahi liya jaata. Figure FIFO conveyor dikhati hai: volatile ke bina doosra cup skip ho jaata hai; volatile ke saath dono cups liye jaate hain.

PICTURE.

Yeh Step 3 ke bug ka mirror image hai: wahan danger tha ek status flag ki bahut kam reads; yahan danger hai ek data port ki bahut kam reads. volatile dono ko fix karta hai "same address, same value" shortcut forbid karke.

Step 7 — Degenerate case: read-only register (const volatile)

KYA HAI. Kuch hardware registers jo tum kabhi write nahi kar sakte (ek status register), phir bhi hardware inhe constantly badalta rehta hai. Yeh ek saath do facts hain:

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

• `const` → tumhara code ise likhne se forbidden hai (ek compile-time promise).
• volatile → hardware ise badalta hai, toh har baar re-read karo.

YEH COMBINE KYUN KARTE HAIN, CLASH NAHI. const software ki writes ko restrict karta hai; volatile hardware ki writes ko describe karta hai. Dono alag actors ke baare mein baat karte hain, isliye dono sach ho sakte hain. Figure register ko do arrows mein split karti hai: tumhare code se ek blocked (coral) arrow, aur chip se ek live (mint) arrow.

PICTURE.

Step 8 — volatile ki limit: yeh atomicity NAHI hai

KYA HAI. volatile int count; count++ ko interrupts ke against safe nahi banata.

KYUN. count++ actually teen alag machine steps hain — ek load, ek add, ek store:

$\underset{\text{1. load}}{\underbrace{R\leftarrow [\text{count}]}}\underset{\text{2. add}}{\underbrace{R\leftarrow R+1}}\underset{\text{3. store}}{\underbrace{[\text{count}]\leftarrow R}}$

volatile guarantee karta hai ki un teeno mein se har ek real memory touch kare — lekin ek interrupt step 1 aur step 3 ke beech aa sakta hai. Figure mein ISR load ke baad sneaking in karta dikhta hai: woh count badhaata hai, phir tumhara store usse overwrite kar deta hai, aur ek increment lost ho jaati hai.

PICTURE.

Sach mein atomic increments ke liye `_Atomic` use karo; kaafi variables mein ordering guarantees ke liye memory barriers use karo. volatile sirf ek variable ki visibility cover karta hai, kuch aur nahi.

Ek picture mein summary

Poora page ek fork in the road hai. Compiler hamesha cache karna chahta hai. volatile woh single flag hai jo decide karta hai ki cached copy trusted hai (bug road) ya har access par discard hoti hai (correct road).