volatile keyword — preventing optimization of hardware registers

5.1.33 · Coding › C Programming

`volatile` KYA hai?

volatile int  flag;            // ordinary volatile int
volatile uint32_t *reg = (volatile uint32_t *)0x40021000; // a hardware register

Key phrase yeh hai: ek volatile access ek observable side effect hai (C standard ke mutabiq), isliye compiler ko ise remove karna forbidden hai.

Hume iska ZAROORAT kyun hai? (first principles)

C standard compiler ko assume karne deta hai ki sirf wahi cheezein memory change karti hain jo operations tumhare translation unit mein visible hain. Usi assumption ke under woh teen optimizations karta hai jo hardware code ko tod deti hain:

Caching in registers — value ko CPU register mein rakho, RAM dobara read karne ki jagah.
Dead-store elimination — agar tum koi value likhte ho aur kabhi read nahi karte, toh woh write "dead" hai, toh delete karo.
Reordering — loads/stores ko idhar-udhar move karo jab tak single-threaded result "waise hi lagta" ho.

Lekin teen cheezein memory ko compiler ki knowledge ke bahar change karti hain:

Change ka source	Example
Memory-mapped hardware register	UART status bit flip hoti hai jab ek byte aata hai
ISR (interrupt service routine)	timer ISR `tick_ready = 1` set karta hai
Doosra thread / DMA	DMA controller ek buffer mein write karta hai

Inke liye, compiler ki assumption galat hai, isliye uski optimizations wrong code produce karti hain. volatile us variable ke liye assumption ko hata deta hai.

Figure — volatile keyword — preventing optimization of hardware registers

Yeh generated code ko KAISE change karta hai

Worked example Classic infinite-loop bug

int flag = 0;            // set by an interrupt
while (flag == 0) { }    // wait for hardware

Yeh kyun toot ta hai: Compiler dekhta hai ki loop ke andar kuch bhi flag ko modify nahi karta. Toh woh flag ko ek baar register R mein read karta hai, phir R pe loop chalta hai. ISR memory copy update karta hai — lekin loop R ko hamesha check karta rehta hai. Hang.

Optimizer jo pseudo-assembly produce karta hai:

    load  R, [flag]      ; read ONCE
L:  cmp   R, 0
    jeq   L               ; R never changes -> infinite loop

Fix:

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

Ab:

L:  load  R, [flag]      ; re-read EVERY iteration
    cmp   R, 0
    jeq   L

Jab ISR memory likhta hai, loop use dekh leta hai.

Worked example Hardware status register padhna

UART ka ek status register hota hai jahan bit 0 = "data ready".

#define UART_SR (*(volatile uint8_t *)0x4000C000)
uint8_t read_byte(void) {
    while (!(UART_SR & 0x01)) { }   // poll until data ready
    return UART_DR;
}

volatile kyun? Iske bina compiler UART_SR ek baar read karta hai. Agar us waqt bit 0, 0 hai, toh woh hamesha ke liye loop karta rahega chahe hardware ise set kar de. Yeh step (& 0x01) kyun? Hum single status bit ko isolate karte hain; register ka baaki part noise/other flags ho sakta hai.

Worked example Do reads jo dono HONI CHAHIYE

volatile uint32_t *DATA = (volatile uint32_t *)0x40000010;
uint32_t a = *DATA;     // reading consumes one FIFO word
uint32_t b = *DATA;     // reading consumes the NEXT word

volatile kyun? Iske bina compiler ek hi address ke do reads dekhta hai, beech mein koi write nahi, decide karta hai woh identical hain, aur doosra read remove kar deta hai (b = a). FIFO ke liye yeh data loss ka bug hai. volatile dono real reads force karta hai. Yeh matter kyun karta hai: read ka khud ek side effect hota hai (FIFO advance karna) — exactly yahi volatile protect karta hai.

QUALIFIER kahaan baithta hai (pointers!)

Pointers ke saath volatile ki placement ka matlab badal jaata hai — ise right-to-left padho:

Common mistakes (steel-manned)

Recall Feynman: ek 12-saal ke bacche ko explain karo

Socho tum ek scoreboard dekh rahe ho, lekin tum lazy ho, toh tum ek baar dekho, "0–0" yaad karo, phir bina upar dekhe "0–0" kehte rehte ho. Agar goal score hota hai, tum purana score kehte rahoge — tumne dekha hi nahi! volatile tumhara woh dost hai jo tumhe poke karta hai: "Hey, har baar ACTUALLY scoreboard dekho, score tab bhi change ho sakta hai jab tum nahi dekh rahe." Computers ke liye, "scoreboard" ek hardware chip ya button hai, aur lazy watcher compiler hai jo time bachane ki koshish kar raha hai.

Active recall

volatile qualifier compiler ko kya batata hai?

Variable kisi bhi waqt, visible code action ke bina, change ho sakta hai, isliye har read/write ek real memory access honi chahiye aur optimize away ya reorder nahi honi chahiye.

Naam bolo teen optimizations jo volatile ek variable ke liye disable karta hai.

Value ko register mein cache karna, dead-store elimination, aur uske accesses ki reordering.

while(flag==0){} volatile ke bina forever loop kyun karta hai jab ISR flag set karta hai?

Compiler flag ko ek baar register mein read karta hai aur us cached copy pe loop karta hai; ISR sirf memory update karta hai, jise kabhi re-read nahi kiya jaata.

Kya volatile count++ ke liye atomicity guarantee karta hai?

Nahi. Har access real memory access hoti hai lekin count++ abhi bhi load-modify-store hai aur interruptible hai; atomicity ke liye _Atomic/mutex use karo.

volatile int *p parse karo.

p ek volatile int ka pointer hai — pointed-to data volatile hai (har baar *p re-read karo). Hardware registers ke liye usual choice.

int * volatile p parse karo.

p khud volatile hai (pointer volatile memory mein rehta hai); jis data ki taraf yeh point karta hai woh ordinary hai.

const volatile ka ek register ke liye kya matlab hai?

Ek read-only hardware register: tumhara code ise kabhi nahi likhta (const) lekin hardware ise change karta hai (volatile), isliye phir bhi har access pe re-read karo.

Optimization band karna volatile ka bura substitute kyun hai?

Yeh sirf accidentally re-reads rakhta hai, fragile hai, higher -O levels pe toot ta hai, aur poore program ko slow karta hai; volatile har optimization level pe sahi hai.

FIFO ke do reads a=*DATA; b=*DATA; volatile kyun use karna chahiye?

Volatile ke bina compiler "redundant" doosra read remove kar deta hai (b=a), agla FIFO word khote hue, kyunki FIFO padhne ka ek side effect hota hai.

Connections

Memory-mapped IO — yahi main reason hai volatile exist karta hai.
Interrupt Service Routines (ISR) — shared flags ko volatile chahiye.
Compiler Optimization Levels (-O0 -O2) — jiske khilaf volatile fight karta hai.
const qualifier — const volatile ke roop mein combine karo.
Atomic operations and _Atomic — volatile YEH nahi hai.
Memory Barriers and Ordering — multicore ke liye volatile se aage chahiye.
Pointers and Type Qualifiers — right-to-left parsing rules.