ARM architecture overview: Exercises — Hinglish deep dive

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

Is page mein sirf wahi assume kiya gaya hai jo ARM architecture overview parent note ne banaya tha: load-store, fixed 32-bit encoding, conditional execution, registers, Thumb, pipelines. Neeche har symbol jahan appear hota hai, wahan turant explain kiya gaya hai.

Level 1 — Recognition

L1.1 — Access pattern ka naam batao

Recall Solution

ARM ek load-store architecture hai: sirf LDR (load register) aur STR (store register) memory ko touch karte hain; arithmetic sirf registers par kaam karti hai.

LDR r0, [r1]    ; address r1 par memory word ko register r0 mein copy karo
ADD r0, r0, #5  ; 5 add karo — ye sirf register-only hai, allowed hai
STR r0, [r1]    ; result ko address r1 par memory mein wapas copy karo

Rule hai load-store principle. Tum ARM par ADD [r1], #5 nahi likh sakte (wo x86 par legal HAI — dekho 5.1.10-x86-architecture).

L1.2 — Condition suffix padho

Recall Solution

Suffix GT = "Greater Than". Har ARMv7 instruction mein ek 4-bit condition field (bits 31–28) hota hai jo run hone se pehle flags ke against check hota hai. ADDGT r1, r1, #1 ka matlab hai: agar last comparison ne flags set kiye hain jo keh rahe hain tested value compared value se greater thi, toh r1 = r1 + 1 compute karo; warna instruction ek NOP ban jaati hai (no-operation, kuch nahi karti) aur phir bhi lagbhag 1 cycle leti hai. Toh ye r1 tabhi change karta hai jab GT condition true ho.

L1.3 — Register field bits count karo

Recall Solution

$N$ registers mein se ek ko naam dene ke liye $⌈ lo g_{2} N ⌉$ bits chahiye. $lo g_{2} 16 = 4 bits$ Ek 32-bit data-processing instruction mein ek condition, opcode, DO register fields (Rn, Rd), aur ek operand pack karna hoga. Har extra register field ko double ya grow karta hai. $16 = 2^{4}$ choose karne se har field exactly 4 bits ban jaata hai — ek clean fit. Bees registers ko 5 bits per field chahiye hote aur encoding space waste hota. Dekho 5.1.07-ARM-instruction-encoding.

Level 2 — Application

L2.1 — Branch-cost formula

Recall Solution

Branch version: $0.15 \times 40 = 6 cycles wasted on average$ Plus the branch instruction itself apna normal cycle toh leta hi hai, lekin prediction se attributable penalty $6$ cycles hai. Conditional-execution version: branch gayab ho jaata hai; guarded instruction ek fixed 1-cycle operation hai (agar condition fail ho toh sirf NOP ban jaati hai). Toh average cost $1$ cycle hai aur misprediction penalty zero hai. Conditional execution se net saving yahan $\approx 6$ cycles per avoided branch hai.

L2.2 — Fetch address arithmetic

Recall Solution

Fixed-width ka matlab hai "next instruction" hamesha == $PC + 4$ == bytes aage hai (32-bit instruction ke liye 4 bytes). Addresses hexadecimal mein hain, jahan 0x10 = 16 decimal. Current instruction 0x8000 par hai; agle teen baar baar 4 add karne se aate hain: $next 1 0 x 8004, next 2 0 x 8008, next 3 0 x 800 C$ (0x800C isliye kyunki 0x8008 + 4 = 0x800C; hex digit C = 12.) Starting address 0x8000 teeno mein se nahi hai, kyunki question uske baad fetch hone wali instructions poochh raha hai. Ye trivial "+4 forever" exactly wahi hai jo variable-length x86 nahi kar sakta — usse apni length jaanne ke liye pehle instruction decode karni padti hai.

L2.3 — Thumb code-size saving

Recall Solution

$30%$ reduction ka matlab hai naya size original ka $70%$ hai. $4000 \times (1 - 0.30) = 4000 \times 0.70 = 2800 bytes$ Saved: $4000 - 2800 = 1200 bytes$ Chhota code instruction cache (6.3.02-cache-memory) mein better fit hota hai → DRAM se slow fetches kam → energy kam (7.1.05-power-optimization).

Level 3 — Analysis

L3.1 — Conditional execution yahan branching ko kyun beat karta hai?

Worked example

Is branchy code ko ARM conditional execution use karke rewrite karo, phir numbers se argue karo (use karo $P_{mis} = 0.15$ , $C_{flush} = 40$ ) ki conditional version average par faster kyun hai. Dhyan se note karo: original mein, MOV r2, #0 unconditionally run hota hai (control hamesha skip label tak pahunchti hai), jabki ADD r1, r1, #1 sirf tab run hota hai jab branch not taken ho (yaani jab r0 > 0 ho).

CMP r0, #0     ; set flags from (r0 - 0)
BLE skip       ; BLE = "Branch if Less than or Equal" -> skip par jaao agar r0 <= 0
ADD r1, r1, #1 ; sirf tab reach hota hai jab r0 > 0
skip:
MOV r2, #0     ; hamesha reach hota hai, dono cases mein run karta hai

Recall Solution

Pehle, ek mnemonic definition: ==BLE== ka matlab hai "Branch if Less than or Equal" — ARM ka branch instruction (B) LE condition ke saath. (ARM branches ke liye B use karta hai, x86-style J for jump nahi.) Toh BLE skip tab skip par jump karta hai jab r0 <= 0 ho, ADD ko skip karte hue.

Semantics jo preserve karni hai:

ADD r1, r1, #1 sirf jab r0 > 0 ho tab hota hai (branch fall through hua).
MOV r2, #0 hamesha hota hai — ye label ke baad hai, toh dono paths isse reach karti hain.

Conditional rewrite (same semantics):

CMP r0, #0        ; set flags from (r0 - 0)
ADDGT r1, r1, #1  ; sirf tab run karta hai agar r0 > 0, warna NOP  (original ADD se match)
MOV r2, #0        ; UNCONDITIONAL — original always-run MOV se match karta hai

MOV ko koi condition suffix nahi milta, kyunki original mein wo har path par execute hota hai. Use guard karna (jaise MOVLE) ek bug hoga: ye MOV ko tab skip kar deta jab r0 > 0 ho aur program ki meaning change ho jaati.

Ab koi branch instruction nahi hai, toh mispredict karne ke liye kuch hai hi nahi. Branch version ki expected cost: BLE apna cycle leti hai plus expected penalty: $P_{mis} \times C_{flush} = 0.15 \times 40 = 6 cycles.$ Conditional version ki cost: har guarded (ya unconditional) instruction outcome ke regardless ek fixed 1 cycle hai — total predictable cost, penalty $= 0$ . Conditional path roughly $6$ cycles per encounter se jeetta hai aur, importantly, uski timing deterministic hai — isliye real-time embedded ARM code ko ye feature pasand aaya karta tha.

L3.2 — Conditional execution kab haarta hai?

Recall Solution

Har guarded instruction phir bhi ek pipeline slot occupy karti hai aur phir bhi ek cycle leti hai chahe wo kuch na kare. Agar $k$ guarded instructions ka poora block run kare lekin condition false ho, toh tumne $k$ NOPs ke liye $k$ cycles pay kiye. Ek branch jo correctly predicted ho lagbhag kuch nahi cost karta aur un $k$ instructions ko entirely skip kar deta hai. Toh break-even roughly hai: $always-pay conditional k vs branch penalty P_{mis} \times C_{flush}$ Jab branch predictors bahut accurate ho gaye ( $P_{mis}$ chhota, jaise $> 95%$ correct toh $P_{mis} < 0.05$ ) toh right side kisi bhi kuch instructions ke block ke liye left se chhota ho jaata hai, aur predicted branches jeet jaate hain. Conditional execution out-of-order cores ko bhi complicate karta hai kyunki ek instruction ko pata nahi hota ki wo "count" karti hai ya nahi jab tak late stage mein condition resolve na ho. Wo trend (great predictors + wide out-of-order machines — dekho 5.2.03-pipelining) exactly wahi hai kyun ARMv8 ne use hata diya.

L3.3 — Banked registers, quantified

Recall Solution

Banking ke bina: entry par tum 5 registers save karte ho (5 cycles), exit par 5 restore karte ho (5 cycles): $5 + 5 = 10 cycles per interrupt.$ FIQ banking ke saath, handler ke paas apne khud ke physical r8–r12 already hain, toh wo interrupted program ki copies ko kabhi touch nahi karta — save ya restore karne ki koi zaroorat nahi. Banking saare 10 cycles remove kar deti hai. Ye kaam kaise karta hai: "banked" ka matlab hai register name r8 mode ke according ek different physical register ko map karta hai. Mode switch karna instantly fresh registers swap in kar deta hai, toh context hardware dwara free mein preserve hoti hai na ki save/restore instructions dwara — Fast Interrupt ka poora point yahi hai.

Level 4 — Synthesis

L4.1 — Full instruction-field budget

Recall Solution

Register fields: $lo g_{2} 16 = 4$ bits each, toh Rn = 4, Rd = 4. Fixed pieces: Cond = 4, format 00 = 2, I = 1, opcode = 4, S = 1. Operand ke alawa sab ka sum: $4 + 2 + 1 + 4 + 1 + 4 + 4 = 20 bits.$ Operand2 ko remainder milta hai: $32 - 20 = 12 bits.$ Total check: $20 + 12 = 32$ ✓ — parent note ke layout se match karta hai (Operand2 bits 11–0 occupy karta hai, jo 12 bits hai). Wo 12 bits ya toh ek small immediate ya ek shifted register encode karte hain (details 5.1.07-ARM-instruction-encoding mein).

Neeche wala figure tumhara answer scale par drawn hai: har coloured box ek field hai, aur 32-bit ruler par uski width uske bit-count ke proportional hai. Ise left-to-right bit 31 (most-significant, Cond) se bit 0 (Operand2) tak padho. Notice karo ki left par chaar fixed lavender/mint/butter/coral boxes exactly 20 bits consume karti hain, right par single wide mint Operand2 box remaining 12 hold karta hai — ye "20 + 12 = 32" balance visualised hai. Jo bhi register tum add karo wo do Rn/Rd boxes ko wider karega aur us right-hand operand box se steal karega.

L4.2 — Register width vs encoding, asli trade-off

Recall Solution

Bits per field $= lo g_{2} N$ ; do fields cost $2 lo g_{2} N$ .

$N$ registers	bits/field	two fields
8	3	6
16	4	8
32	5	10

ARMv7 ne 16 choose kiya. Aath registers bahut zyada memory par spill karti hain (zyada slow LDR/STR). Battees sirf do register names par 32 bits mein se 10 bits kha jaata, operand/immediate space ko starve karta. Solah har field ko ek clean 4 bits rakhta hai (byte-aligned layout mein fit hota hai) jabki itne registers deta hai ki zyaatar kaam memory se door rakh sako — (a) aur (b) ke beech ka balance point.

Level 5 — Mastery

L5.1 — Pipeline-depth argument design karo

Worked example

ARM7 ek 3-stage pipeline use karta hai (Fetch, Decode, Execute); modern Cortex-A cores 8–15 stages use karte hain. Deeper pipeline se clock frequency raise kar sakte ho lekin branch-misprediction flush size badh jaati hai (roughly fetch aur jahan branch resolve hoti hai ke beech stages ki sankhya).

Do designs same 1000-instruction program process karte hain jismein $20%$ instructions branches hain with misprediction probability $P_{mis} = 0.10$ :

Design A: 3-stage pipeline, clock $1.0$ GHz, flush penalty $C_{A} = 2$ cycles.
Design B: 12-stage pipeline, clock $2.5$ GHz, flush penalty $C_{B} = 11$ cycles.

Assume 1 cycle per non-stalling instruction. Har ek ke liye total cycles phir total time compute karo, aur decide karo kaunsa design faster hai. (1 GHz $= 1 0^{9}$ cycles/second, toh time $=$ cycles $/$ frequency.)

Recall Solution

Step 1 — mispredictions count karo (dono ke liye same). Branch instructions: $1000 \times 0.20 = 200$ . Inmein se, mispredicted: $200 \times 0.10 = 20 mispredictions.$

Step 2 — Design A cycles. Base ek cycle per instruction plus $C_{A} = 2$ cycles per misprediction: $cycles_{A} = 1000 + 20 \times 2 = 1000 + 40 = 1040 cycles.$ Design A time. Cycles ko frequency $1.0 GHz = 1.0 \times 1 0^{9}$ cycles/s se divide karo: $t_{A} = \frac{1040}{1.0 \times 1 0 ^{9}} s = 1.040 \times 1 0^{- 6} s = 1040 ns.$

Step 3 — Design B cycles. Base plus $C_{B} = 11$ cycles per misprediction: $cycles_{B} = 1000 + 20 \times 11 = 1000 + 220 = 1220 cycles.$ Design B time. Frequency $2.5 GHz = 2.5 \times 1 0^{9}$ cycles/s se divide karo: $t_{B} = \frac{1220}{2.5 \times 1 0 ^{9}} s = 4.88 \times 1 0^{- 7} s = 488 ns.$

Step 4 — compare aur conclude karo. Halankeh B zyada cycles karta hai ( $1220 > 1040$ ), uska $2.5 \times$ higher clock har cycle ko bahut shorter banata hai, toh: $t_{B} = 488 ns < t_{A} = 1040 ns, \frac{t _{A}}{t _{B}} = \frac{1040}{488} \approx 2.13.$ Design B lagbhag $2.13 \times$ faster hai. Exactly isliye high-performance ARM cores deep pipelines accept karte hain aur strong branch predictors (5.2.03-pipelining) par lean karte hain — frequency gain flush cost se outweigh karta hai jab tak prediction achhi rahe. Agar $P_{mis}$ sharply badhe, toh B ka larger flush penalty ( $C_{B} = 11$ vs $C_{A} = 2$ ) us advantage ko erode kar deta aur eventually reverse kar deta.

L5.2 — ARMv8 conditional-execution removal end-to-end argue karo

Recall Solution

Teen linked points:

6-cycle saving ek bure predictor ko assume kar raha tha ( $P_{mis} = 0.15$ , $C_{flush} = 40$ ). Modern ARM cores $> 95%$ correctly predict karte hain, toh realistic penalty $P_{mis} \times C_{flush} = 0.05 \times C_{flush}$ hai — pehle ke figure ka third ya less.
Conditional execution always-paid hai (L3.2): $k$ guarded instructions ka ek block $k$ cycles cost karta hai chahe skip ho jaye, jabki ek correctly predicted branch almost kuch nahi cost karta. Achhe predictors ke saath, $P_{mis} \times C_{flush} < k$ typical blocks ke liye, toh branching average par jeet jaata hai.
Ye out-of-order execution se ladhta hai (L3.2): ek instruction jo nahi jaanti ki wo "count" karti hai ya nahi jab tak uski condition resolve na ho, wide, deep machines (L5.1) ko complicate karti hai jo ARMv8 ko uski speed deti hain. Toh removal ek regression nahi thi — isne un deeper, faster, out-of-order pipelines ko enable kiya jinka frequency advantage (L5.1) purane conditional-execution trick se kahin zyada hai. Engineer ka number real hai lekin obsolete: wo 1990s ke slow, shallow, poorly-predicting cores se belong karta hai.