ARM architecture overview: Visual walkthrough — Hinglish deep dive

5.1.6 · D2 · Hardware › Instruction Set Architecture (ISA) › ARM architecture overview

Intuition Hum yahan kya build kar rahe hain

ARM overview ne ek bold number claim kiya tha: $Cycles saved \approx P_{mispredict} \times C_{flush} \approx 0.15 \times 40 = 6 cycles/branch$ Yahan $P_{mispredict}$ simply wo fraction hai jitni baar CPU branch ka galat guess karta hai (yahan $0.15$ , matlab 15%), aur $C_{flush}$ hai kitne cycles waste hote hain har baar jab wo galat guess karta hai — hum dono ko neeche carefully build karenge, toh abhi opaque lage toh tension nahi. Wo ek line poori ek kahani chhupa leti hai — ek CPU instructions kaise "khata" hai. Is page par hum zero se shuru karte hain — "pipeline hoti kya hai?" — aur wo formula picture by picture build karte hain. End tak aap dekhenge kyun ARM almost har instruction par ek chhoti si condition tag kyun stamp karta hai, instead of idhar-udhar jump karne ke.

Neeche sab kuch sirf ek cheez assume karta hai: ek computer instructions ek ke baad ek, upar se neeche run karta hai, jaise koi list padh rahe ho. Baaki sab hum khud build karte hain.

Step 1 — Pipeline actually hoti kya hai

KYA HAI. Ek modern CPU ek instruction finish nahi karta agla shuru karne se pehle. Ye ek laundromat ki tarah kaam karta hai: jab shirt #1 dry ho rahi hoti hai, shirt #2 already wash ho rahi hoti hai. Har instruction stages se guzarta hai. Classic ARM7 mein teen hain:

Fetch (F) — memory se agla instruction grab karo.
Decode (D) — samjho iska matlab kya hai (kaunsa operation, kaunse registers).
Execute (E) — actually arithmetic karo.

KYUN. Agar har stage ek cycle (CPU clock ki ek tick) leti hai, toh unhe ek-ek karke karna time waste karta hai: "fetch" hardware idle baitha rehta hai jab "execute" chal raha hota hai. Unhe overlap karne se har piece of hardware har cycle busy rehta hai.

PICTURE. Neeche coloured diagonal dekho. Har row ko ek clock cycle ki tarah padho (time neeche jaata hai). Neeche payoff dikhta hai: pipe full hone ke baad, ek instruction har single cycle finish hoti hai, chahe personally har ek ko 3 cycles lagte hon.

Step 2 — Branch ek fork in the road hai

KYA HAI. Branch ek instruction hai jo kehti hai "shayad kahin aur jump karo." Example:

CMP r0, #0      ; compare r0 to 0, record the result in flags
JLE skip        ; Jump if Less-or-Equal — go to 'skip' if r0 <= 0
ADD r1, r1, #1  ; otherwise run this
skip: ...

YE DANGEROUS KYUN HAI. Step 1 yaad karo: CPU agla instruction fetch karta hai current instruction finish hone se pehle. Lekin JLE ke baad agla instruction kaunsa hai? Ye CMP ke result par depend karta hai — jo abhi execute nahi hua! Fetch stage ko guess karna padta hai.

PICTURE. Rasta do hisson mein banta hai. CPU fork par aankhen band karke khada hai, aur use ek raaste par chalna shuru karna hai signpost (CMP ke flags) padhne se pehle.

Step 3 — Guess, aur galat guess karne ki cost

KYA HAI. CPU ek branch predictor use karta hai: hardware ka ek piece jo past history ke basis par "taken" ya "not taken" bet lagata hai. Sahi bet lage toh almost koi time waste nahi. Bet galat lage toh, wo sab instructions jo galat path par fetch ki thi wo sab garbage hain aur phenk deni padti hain — ek pipeline flush.

YE ITNA DARDNAK KYUN HAI. Step 1 mein pipe useful kaam se bhari thi. Flush usse khali kar deta hai. CPU ko correct path se re-fetch karna padta hai aur har stage scratch se refill karni padti hai — pure waste ke cycles.

PICTURE. Predictor ne "right jaao" guess kiya, pipe ko red (wrong-path) instructions se bhara, phir pata chala sach tha "left jaao". Dekho saari red work trash mein kaise jaati hai, aur pipe dubara shuru hoti hai.

Definition Flush penalty (aur ye sirf

roughly pipeline depth kyun hai) Ek first-order estimate hai: $C_{flush} \approx (pipeline stages between Fetch and where the branch is resolved)$

$C_{flush}$ :: cycles waste hote hain har mispredict par.
Short 3-stage ARM7 → chhoti penalty (~2). Deeper cores → badi.

Lekin ye ek floor hai, poori sachai nahi. Real penalty ko wo hardware shape karta hai jo simple formula ignore karta hai:

Ek branch-target buffer (BTB) target Fetch ke dauran supply kar sakta hai, correctly predicted taken branch ki cost ka zyada hissa chhupa deta hai.
Decode/dispatch timing aur partial stage overlap ka matlab hai branch "one stage per cycle" se pehle ya baad mein resolve ho sakta hai.
Out-of-order cores par, recovery mein register-rename map rewind karna aur issue slots reclaim karna bhi hota hai, jo raw depth se upar cycles add kar sakta hai.

Inhi sab ki wajah se, real Cortex-A designs par published mispredict penalties commonly ~15–20 cycle range mein hoti hain, koi ek universal number nahi.

Step 3½ — Sahi guess bhi perfectly free nahi hota

KYA HAI. Clean claim "correct prediction costs 0" ek simplification hai. Real pipelines par, correctly predicted taken branch aksar thodi cost karta hi hai: kam se kam resolution latency (branch ko pehchana jaana aur uska target form hona), aur agar BTB pehli baar miss kare, toh 1–2 cycle bubble jab front-end redirect hoti hai.

YE KYUN IMPORTANT HAI. Iska matlab hai branches kabhi sach mein free nahi hote, toh hamare model mein ek chhupa hua teesra term hai. Maano $C_{ok}$ correctly predicted branch ki chhoti penalty hai (often $\approx 1$ cycle taken branch ke liye, $\approx 0$ not-taken ke liye).

PICTURE. Step 4 ka green "correct" slice floor par flat nahi hai — wo zero se thoda upar baitha hai. Chhota, lekin honest.

Step 4 — Branch ki average cost (dominant term)

KYA HAI. Har branch mispredict nahi karta. Maano predictor 85% time sahi hota hai. Toh ek fraction $P_{mispredict} = 0.15$ branches poora flush price pay karte hain; baaki sirf Step 3½ ka chhota $C_{ok}$ pay karte hain. Us chhote toll ko abhi ignore karte hue, average extra cost mispredict term se dominate hoti hai.

MULTIPLY KYUN, ADD NAHI. Hum bahut saare branches mein expected waste chahte hain. Probability $\times$ penalty exactly wahi hai jo "expected cost" ka matlab hai: ek rare disaster aur ek common near-free pass, ek number mein blend.

PICTURE. Ek bar do slices mein split — tall-but-thin red slice (rare, costs 40) aur wide green slice (common, costs small $C_{ok} \approx 1$ , floor se thoda upar draw kiya). Dashed line average height hai: effective cost jo har branch "deta" hai.

Toh average par, is model mein har branch roughly 6 wasted cycles cost karta hai. Ab ARM poochhta hai: kya hum branch ko poori tarah avoid kar sakte hain?

Step 5 — ARM ka trick: instruction ko tag karo, jump mat karo

KYA HAI. Har ARMv7 instruction bits 31–28 mein ek 4-bit condition field carry karta hai (encoding table parent note mein dekho). Instruction tabhi run hoti hai jab flags match karein; warna wo silently NOP ban jaati hai (no-operation — sirf apna ek cycle occupy karta hai aur kuch nahi karta).

CMP r0, #0        ; set flags from r0 - 0
ADDGT r1, r1, #1  ; ADD, but only 'if Greater Than'  — else a 1-cycle NOP
MOVLE r2, #0      ; MOV,  only 'if Less-or-Equal'     — else a 1-cycle NOP

YE POORI PROBLEM KYUN AVOID KARTA HAI. Koi fork in the road nahi hai. CMP ke baad ki instructions hamesha memory mein agali hoti hain — fetch stage ko kabhi guess nahi karna padta. Condition baad mein, pipeline ke andar check hoti hai, aur sirf decide karti hai ki result write hoga ya drop. Kabhi koi wrong path fetch nahi hota → koi flush possible nahi hai.

PICTURE. Dono timelines side by side compare karo. Upar (branch version): ek fork, ek galat guess, ek red flush. Neeche (conditional version): ek straight pipe, kuch instructions NOPs ki tarah grey-out, lekin kabhi koi bubble nahi.

Step 6 — Break-even line (har case covered)

KYA HAI. Predication actually kab jeetta hai? Maano ek conditional block mein $n$ instructions hain, jinmein se ek false condition $n$ NOP cycles waste karti. Isse compare karo unke around branch karne ki cost $C_{branch} \approx 6$ se.

LINE KYUN KHAINCHEIN. Hume sab cases cover karne chahiye, sirf happy wala nahi. Chhota $n$ → predication jeetta hai. Bada $n$ → branch jeetta hai. Ek crossover hota hai.

PICTURE. Block size $n$ ke against do cost lines: flat branch cost (about 6, ek baar mispredict ho) aur rising predication cost ( $n$ NOP cycles). Jahan ye cross karte hain wo decision boundary hai.

Ek-picture summary

Poori chain ek image mein: ek full pipe (IPC = 1) → ek branch usse fork karta hai → ek galat guess usse flush karta hai (aur sahi guess bhi ek chhota toll cost karta hai) → average karo toh hamare teaching model mein ~6 cycles cost hoti hai → ARM fork ko ek tagged straight-line pipe se replace karta hai jo NOP kar sakti hai lekin kabhi bubble nahi → lekin bade blocks ke liye NOP tax branch se zyada ho jaata hai, isliye deep, well-predicted pipelines ne ultimately ye trick retire kar di.

Recall Feynman retelling — plain words mein bolein

CPU instructions ek assembly line ki tarah padha karta hai: jab ek ho rahi hoti hai, agli already fetch ho rahi hoti hai. Ye tabhi kaam karta hai jab use pata ho aage kya aata hai. Branch ye tod deta hai — ye ek fork hai, aur machine ko ek raaste par chalna shuru karna padta hai answer ready hone se pehle. Sahi guess karo, toh almost kuch nahi laagta (ek chhota resolution/target toll, shayad 1 cycle). Galat guess karo, toh jo bhi shuru kiya tha sab dump karna padta hai aur line refill karni padti hai — ek deep out-of-order core par wo roughly 15–40 cycles hoti hai design ke hisaab se. Kyunki guesses 15% time galat hote hain, har branch quietly average par kuch cycles cost karta hai (hamare tidy numbers se, roughly $0.15 \times 40 = 6$ ). ARM ka clever move: fork hi mat karo. Har instruction par ek chhota "only if…" tag stamp karo. Line straight rehti hai, koi bhi kabhi wrong path par fetch nahi hota, aur skipped instructions sirf ek tick ke liye kuch nahi karte. Ye ek bargain hai jab tak aap sirf ek handful skip kar rahe ho — roughly six instructions tak. Isse zyada skip karo aur ek clean jump better hota — exactly isliye 64-bit ARMv8, excellent modern predictors ke saath, ye trick chhod deta hai aur branch predictor par trust karta hai. Ek saans mein lesson: forks expensive hain kyunki ye guess force karte hain; instructions ko tagging karna guess hi avoid karta hai — chhote, unpredictable conditionals ke liye ek great deal, aur lambe blocks ke liye ek poor one.

Recall Quick self-test

Ek predicated (conditional) instruction pipeline flush kyun nahi cause kar sakti? ::: Kyunki memory mein uske baad wali instruction hamesha agali fetch hoti hai — koi fork nahi, toh fetch stage kabhi guess nahi karta, toh un-guess karne ko kuch nahi. Honest branch-cost formula mein kaunsi teen quantities appear karti hain? ::: Correct-prediction toll $C_{ok}$ , mispredict probability $P_{mispredict}$ , aur flush penalty $C_{flush}$ . Kya $C_{flush} \approx 40$ ek real spec hai? ::: Nahi — ye ek pessimistic teaching figure hai; real Cortex-A mispredict penalties commonly ~15–20 cycles hoti hain, BTBs, decode/dispatch timing aur out-of-order recovery se shaped. ARMv8 ne conditional execution kyun remove kiya? ::: Modern branch predictors 95% se zyada accurate hain (toh $C_{branch}$ tiny hai) aur predication out-of-order execution ko complicate karta hai; chhote se chhote blocks ko chhod kar, ek clean branch ab jeetta hai. Kya $C_{cond}$ aur $C_{NOP}$ same cheez hain? ::: Haan — dono 1 cycle equal hain; $C_{cond}$ kisi bhi predicated instruction ki cost name karta hai, $C_{NOP}$ sirf us instruction ki cost stress karta hai jiska condition false tha.

See also: 5.1.07-ARM-instruction-encoding (jahan 4-bit condition field rehta hai) · 5.2.03-pipelining (stages in depth) · 6.3.02-cache-memory (kyun fewer/smaller instructions help karte hain) · 7.1.05-power-optimization (fewer flushes = less wasted energy) · 5.1.10-x86-architecture (variable-length contrast).