5.1.6 · D3 · HinglishInstruction Set Architecture (ISA)

Worked examplesARM architecture overview

4,256 words19 min read↑ Read in English

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

Matrix se pehle, hume har symbol earn karna hoga taaki kuch bhi undefined na lage.

Figure — ARM architecture overview

The scenario matrix

Neeche har cell ek alag cheez hai jo ho sakti hai. Baad ke examples apne cell(s) ka naam lete hain.

# Cell class Concrete trigger Example
A Equal operands a == bZ=1 Ex 1
B Signed, positive result, no overflow a > b, dono small Ex 2
C Signed, negative result a < b Ex 3
D Signed vs unsigned disagree top-bit ("negative-looking") number Ex 4
E Overflow flips the sign (limiting case) INT_MAX + 1 Ex 5
F Zero / degenerate input compare to #0; always/never conditions Ex 6
G Carry semantics on subtract (HS/LO) borrow vs no-borrow Ex 7
H Real-world word problem sensor value clamp karo, branch-free Ex 8
I Exam twist reorder jo silently flags tod deta hai Ex 9
J LS/LE "or-equal" boundary operands exactly equal at the edge Ex 10

Ex 1 — Cell A: operands equal (Z = 1)

Forecast: aage padhne se pehle r2 guess karo — aur guess karo ki N lit hai ya nahi.

  1. Compute r0 - r1 = 42 - 42 = 0. Yeh step kyun? CMP hai hi subtraction; flags is hidden result se aate hain.
  2. 0 se flags set karo. Kyun? Z=1 (result zero hai), N=0 (0 negative nahi hai), aur subtraction ke liye C = NOT borrow: 42-42 ko koi borrow nahi chahiye, toh C=1. V=0 (koi signed overflow nahi). Yahan C ki kyun parwah? EQ ke liye nahi, lekin tumhe hamesha charon track karne chahiye — baad ki instruction unhe read kar sakti hai.
  3. MOVEQ reads Z==1 → true → runs, toh r2 = 1. Kyun? EQ exactly Z==1 defined hai, aur MOV simply constant 1 ko r2 mein drop karta hai.
  4. MOVNE reads Z==0 → false → NOP ban jaata hai. Kyun? NE logical opposite hai; pair mein sirf ek hi kabhi fire karta hai, toh r2 0 se overwrite nahi hota.

Verify: equal inputs se "equal" branch milna chahiye → r2 = 1. ✓ Aur exactly EQ/NE pair mein se ek execute hua, jaise required hai.


Ex 2 — Cell B: signed, positive, no overflow

Forecast: kya 7 > 3 "GT-true" hai? N aur V ko kya hona chahiye?

  1. r0 - r1 = 7 - 3 = 4. Kyun? Comparison ki hidden subtraction.
  2. Flags: Z=0 (4≠0), N=0 (4 positive), V=0 (no overflow), C=1 (no borrow). Kyun V=0? Dono numbers tiny hain, result easily fit ho jaata hai.
  3. GT ko chahiye Z==0 AND N==V. Yahan Z=0 ✓ aur N=V=0 ✓ → fires. Kyun sirf N==0 test karne ki jagah N==V test? Kyunki overflow sign ke baare mein jhooth bol sakta hai; N==V honest "kya yeh sach mein positive hai?" test hai. Hum ise Ex 5 mein apna kaam karte dekhenge.
  4. r2 = 10 + 1 = 11. Yeh step kyun? ADDGT fired, toh ADD normally run karta hai: purana r2 (10) leta hai, immediate 1 add karta hai, aur 11 wapas r2 mein write karta hai. Agar GT fail hota, toh yeh poori line NOP hoti aur r2 10 pe rehta.

Verify: 7 > 3 true hai → r2 increment hua → 11. ✓


Ex 3 — Cell C: signed, negative result (N=1, V=0)

Forecast: 3 < 7 true hai — lekin kaunsa flag combination prove karta hai "less than"?

  1. r0 - r1 = 3 - 7 = -4. Kyun? Phir se hidden subtraction.
  2. Flags: result -4N=1, Z=0, V=0 (numbers small, no overflow). C=0 kyunki 3-7 ko borrow ki zaroorat padi (unsigned 3 < 7). Kyun C=0 yahan hai lekin Ex 2 mein C=1 tha? Subtract C = NOT borrow set karta hai; yahan borrow hua tha.
  3. LT ko chahiye N != V. N=1, V=0 → yeh differ karte hain → fires. Kyun N!=V plain N==1 ki jagah? Same reason as GT: sirf combination overflow survive karta hai. Jab koi overflow nahi (V=0), LT collapse ho jaata hai bas "N=1" mein, jo intuition se match karta hai.
  4. r2 = 10 - 1 = 9. Yeh step kyun? SUBLT fired, toh SUB run karta hai: purana r2 (10) leta hai, immediate 1 subtract karta hai, aur 9 wapas write karta hai. Agar LT fail hota toh line NOP hoti aur r2 = 10 rehta.

Verify: 3 < 7 true → decrement → 9. ✓


Ex 4 — Cell D: signed vs unsigned DISAGREE

Yeh woh cell hai jahan sabse zyaada log galti karte hain. Same bits "greater" ka alag jawab dete hain depending on whether tumne GT (signed) ya HI (unsigned) pucha.

Figure — ARM architecture overview

Forecast: 0xFFFFFFFF sabse bada 32-bit pattern hai. Zaroor yeh "greater" hai... ya hai?

  1. 0xFFFFFFFF ki do readings. Kyun? Bits mein khud koi sign nahi hota. Unsigned mein yeh 4294967295 hai (bahut bada). Signed mein (top bit 1) yeh -1 hai (tiny). Cell D ka yahi poora point hai — aur figure mein exactly yahi do dots hain.
  2. Hidden subtraction r0 - r1: 0xFFFFFFFF - 1 = 0xFFFFFFFE. Signed mein yeh -2 hai. Yeh step kyun? CMP hai hi subtraction; hume uske flags chahiye, toh pehle discarded result compute karna hoga.
  3. Flags: result ka top bit 1 hai → N=1. Z=0. V=0 (signed -1 - 1 = -2 theek se fit ho jaata hai, koi overflow nahi). C=1 (unsigned 4294967295 - 1 ko koi borrow nahi chahiye).
  4. GT (Z==0 AND N==V): N=1, V=0N != Vfails. Toh r2 unchanged rehta hai (0 rehta hai). Kyun? Signed mein, -1 > 1 false hai.
  5. HI (C==1 AND Z==0): C=1, Z=0fires, r3 = 1. Kyun? Unsigned mein, 4294967295 > 1 true hai.

Verify: signed kehta hai no (-1 > 1 false), unsigned kehta hai yes (4294967295 > 1 true) → r2 = 0, r3 = 1. ✓ Do flags, ek number, opposite answers — exactly isliye ARM mein dono GT aur HI hain.


Ex 5 — Cell E: overflow flips the sign (limiting case)

Forecast: INT_MAX + 1 — number hona chahiye positive-ish, lekin bits...

  1. Add: 0x7FFFFFFF + 1 = 0x80000000. Kyun bits note karein? 0x80000000 ka top bit 1 hai → sabse zyaada negative signed value ki tarah read hota hai, -2147483648.
  2. Flags: N=1 (top bit set). Z=0. C=0 (bit 31 se koi unsigned carry out nahi). Aur crucially V=1: humne do positives add kiye aur negative mila — sign impossible hai, toh overflow flag ho gaya. Hardware V ki parwah kyun karta hai? Exactly taaki conditionals is trap se survive kar sakein.
  3. GE ko chahiye N == V. Yahan N=1, V=1equal → fires! r2 = 1. Yeh "correct" answer kyun hai? Mathematically 2147483647 + 1 = 2147483648 positive hai. Raw bits negative lagte hain (N=1), lekin V=1 kehta hai "sign bit jhooth bol raha hai," aur N==V use un-jhoothaata hai. Agar hum naively N==0 test karte, hum galti se ise negative bolte.

Verify: true math result positive hai → GE fires → r2 = 1, aur yahi wajah hai ki GE N==V use karta hai, N==0 nahi. ✓


Ex 6 — Cell F: zero input aur always/never conditions

Forecast: inme se kitne fire karte hain?

  1. r0 - 0 = 0. Kyun? Degenerate input #0 se compare karna — sabse cheap possible test, isliye ARM assembler aksar CMP r0, #0 ko "kya yeh zero / negative hai?" ek shot mein detect karne deta hai.
  2. Flags: Z=1, N=0, V=0, C=1 (0 subtract karna koi borrow nahi karta).
  3. ADDEQ (Z==1) → fires, r1 = 6. Kyun? EQ exactly Z==1 hai; hidden subtraction ne 0 diya, toh flag set hai aur ADD run karta hai, purana r1 (5) + 1 = 6 leta hai.
  4. ADDALAL (ALways) woh default condition hai jo har plain instruction carry karta hai. Koi flags nahi padhta, hamesha run karta hai. r1 = 6 + 10 = 16. AL suffix ki zaroorat kyun hai? Taaki 4-bit condition field kabhi "empty" na ho — ek unconditional instruction bas AL code 1110 store kar leta hai.
  5. NV ("never") code (1111) AL ka degenerate opposite tha: ek instruction jo kabhi nahi chalti, ek permanent NOP. Kaunse versions mein? Original 32-bit ARM ISA ARMv4 tak, NV genuinely "never execute" matlab tha. ARMv5 se aage ARM ne 1111 code ko unconditional special instructions (jaise BLX, PLD) ke liye repurpose kiya, toh NV ka matlab "never" nahi raha — modern cores par ise NOP ki tarah use mat karo.

Verify: EQ fires (+1) aur AL fires (+10) → 5 + 1 + 10 = 16. ✓


Ex 7 — Cell G: subtraction par carry semantics (HS/LO)

Forecast: kya bigger-minus-smaller case C set ya clear karta hai?

  1. Case (i): 10 - 3 = 7. Unsigned, 10 >= 3, toh koi borrow nahi chahiye. Yeh kyun matter karta hai? Rule: subtraction C = NOT borrow set karta hai. No borrow → C=1.
  2. Case (ii): 3 - 10 = -7 (bits 0xFFFFFFF9). Unsigned 3 < 10, toh borrow huaC=0.
  3. Table se HS/LO ke through interpretation: CMP ke baad, HS (C==1) matlab "a >= b unsigned"; LO (C==0) matlab "a < b unsigned". Toh case (i) mein HS-conditional fire karega aur LO-conditional NOP; case (ii) mein ulta. Yeh naive intuition ka ulta kyun hai? Log expect karte hain "carry = kuch galat hua." Subtract ke liye yeh deliberately inverted hai taaki HS/LO cleanly unsigned >= / < ki tarah read karein.

Verify: case (i) C=1 (no borrow, 10>=3, toh HS fires); case (ii) C=0 (borrow, 3<10, toh LO fires). ✓


Ex 8 — Cell H: real-world word problem (branch-free clamp)

Recall Quick recap: "branch-free" itni mehnat kyun karti hai

Ek branch (jump jaise JLE) jo CPU galat predict kare ek pipeline flush force karta hai — jo instructions already in-flight hain unhe throw away karta hai. Parent note ne us cost ko estimate kiya cycles wasted per branch. Yahan fraction of branches hai jinhein predictor galat get karta hai (0 aur 1 ke beech pure probability, toh 0.15 = "15% time galat"), aur har misprediction par throw away hone wale pipeline-cycles ki number hai (units: cycles; 40 ek deep modern pipeline ke liye typical hai). Unka product ke units hain cycles per branch — average penalty. Conditional execution jump se bilkul bachta hai (ek failed instruction bas 1-cycle NOP hai), toh hum woh penalty dodge karte hain. Zyaada gehri pipeline mechanics 5.2.03-pipelining mein hain.

Forecast: 137 ke liye, dono MOVs mein se kaunsa fire karta hai?

  1. Pehla CMP r0, #0 with r0 = 137: 137 - 0 = 137, toh N=0, V=0, Z=0. Kyun? Pehle low edge check karo; hidden subtraction woh flags deta hai jo MOVLT read karega.
  2. MOVLT ko chahiye N != V; N=0=V → equal → NOP. r0 137 rehta hai. NOP kyun? 137 < 0 nahi hai, toh hume ise floor nahi karna chahiye.
  3. Doosra CMP r0, #100: 137 - 100 = 37, toh Z=0, N=0, V=0. Re-compare kyun? Ab hum high edge test karte hain; pehle wale flags stale hain, toh hume unhe refresh karna hoga (exactly yeh staleness Ex 9 mein bite karta hai).
  4. MOVGT ko chahiye Z==0 AND N==V; Z=0, N=V=0fires, r0 = 100. GT kyun, GE nahi? 100 khud allowed hai, toh hum tabhi cap karte hain jab 100 se strictly zyaada ho.

Verify: input 137 clamp hokar 100 banta hai; aur construction se code mein zero branches hain, toh koi pipeline flush penalty nahi. ✓


Ex 9 — Cell I: exam twist (ek instruction silently flags clobber karta hai)

Forecast: 9 > 2 obviously true hai — zaroor MOVGT runs?

  1. CMP r0, r1 woh flags set karta hai jo hum chahte hain: 9 - 2 = 7Z=0, N=0, V=0GT true hota. Kyun? Abhi tak sahi hai — yahi woh flag state hai jo GT fire karwata.
  2. ADDS r4, r5, r6 S par end hota hai, toh yeh N/Z/C/V overwrite karta hai. Yeh trap kyun hai? Sirf S-suffixed instructions (aur CMP) flags touch karte hain — lekin yeh wala karta hai. CMP result ab gone hai, ek unrelated addition ke flags se replace ho gaya.
  3. ADDS jo 0 de raha hai usse naye flags: Z=1, N=0, V=0. Kyun? 0 ka sum Z set karta hai, jaise koi bhi zero result.
  4. MOVGT ko chahiye Z==0 AND N==V; ab Z=1fails → NOP. r3 set nahi hota. Bug! Kyun hua? Unrelated ADDS CMP aur uske dependent conditional ke beech baitha aur Z reset kar diya.
  5. Fix: ya toh ADDS ko MOVGT ke baad move karo, ya plain ADD use karo (koi S nahi) taaki flags alone rahein. ADD vs ADDS itna kyun matter karta hai? S bit (encoding mein bit 20 — dekho 5.1.07-ARM-instruction-encoding) sirf yehi "update flags" aur "unhe chhodd do" ko separate karta hai.

Verify: buggy code se MOVGT fire nahi karta (kyunki Z=1 ADDS 0 ke baad), even though 9 > 2. ✓ Lesson: conditional execution last flag-setter par depend karta hai, last CMP par nahi.


Ex 10 — Cell J: the "or-equal" boundary (LS aur LE)

Forecast: 5 <= 5 true hai ("equal" half). Lekin kya flag formulas ise actually pakdte hain?

  1. r0 - r1 = 5 - 5 = 0. Kyun? Hidden subtraction — aur yeh exactly us boundary case par land karta hai jahan equality matter karti hai.
  2. Flags: Z=1 (result 0), N=0, V=0, C=1 (no borrow, 5 >= 5).
  3. LS ko chahiye C==0 OR Z==1. Yahan Z=1fires, r2 = 1. OR Z==1 clause kyun exist karta hai? Kyunki equality par C=1 hota hai (jo akela "higher" kehta), toh formula ko "equal" ko bhi <= count karne ke liye extra Z==1 term chahiye. Iske bina, 5 <= 5 galti se fail hota.
  4. LE ko chahiye Z==1 OR N!=V. Yahan Z=1fires, r3 = 1. Z==1 term phir kyun? Equality par N==V hota hai (toh N!=V "strictly less" part false hai); Z==1 term hi "or-equal" case ko rescue karta hai.

Verify: 5 <= 5 true hai dono signed aur unsigned mein → dono fire karte hain → r2 = 1, r3 = 1. ✓ Har formula mein Z==1 clause exactly "or-equal" half hai jo boundary par apna kaam karta hai.


Recall Self-check

CMP r0, r1 ke baad r0=0xFFFFFFFF, r1=1 se: kya MOVGT fire karta hai? ::: Nahi — signed mein woh -1 > 1 hai = false (N != V, toh GT fail karta hai). Same CMP ke baad, kya MOVHI fire karta hai? ::: Haan — unsigned 4294967295 > 1 = true (C=1, Z=0). INT_MAX + 1 ADDS ke through: kaunse flags? ::: N=1, Z=0, C=0, V=1 — aur GE correctly fire karta hai kyunki N==V. Subtraction C = kya set karta hai? ::: NOT borrow — toh C=1 (yaani HS) matlab unsigned a >= b. CMP 5,5 par, kya LS aur LE fire karte hain? ::: Haan — dono kyunki Z==1 "or-equal" half supply karta hai. Har plain instruction ka default suffix kaunsa hai? ::: AL (always), condition code 1110. Kya NV ka matlab abhi bhi "never" hai? ::: Sirf ARMv4 tak; ARMv5 se 1111 code ko unconditional special instructions ke liye repurpose kiya gaya. Kaunsi ek cheez decide karti hai ki ADD flags update karta hai ya nahi? ::: S suffix (ADDS update karta hai, ADD nahi).

Aage kahan jaana hai: S bit aur condition field ka bit-level ghar 5.1.07-ARM-instruction-encoding hai; branch-free code kyun help karta hai yeh 5.2.03-pipelining mein gehraaya gaya hai; energy angle 7.1.05-power-optimization se link karta hai aur density story 6.3.02-cache-memory se. Poori conditional-execution idea ko 5.1.10-x86-architecture se contrast karo, jo branch prediction par rely karta hai.