ARM architecture overview: Question bank — Hinglish deep dive

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

Shuru karne se pehle, teen words jinpe hum baar baar rely karte hain — inhein ek baar theek se samjho taaki reveals ka sense bane:

True or false — justify

Har answer mein reason dena hai, sirf T/F nahi.

T/F: ARM mein, ek ADD instruction seedha memory se ek operand read kar sakta hai.

False. ARM ek load-store architecture hai: sirf LDR/STR memory touch karte hain, isliye ADD ke operands pehle se registers mein hone chahiye. Pehle alag se LDR lagega.

T/F: Fixed 32-bit instruction width ka matlab hai ARM programs hamesha x86 programs se chote hote hain.

False. Fixed width sirf decoding ko simplify karta hai, lekin ek simple MOV r0,#1 phir bhi poore 32 bits leta hai chahe usse itne ki zarurat na ho — exactly isliye Thumb exist karta hai code ko shrink karne ke liye.

T/F: Conditional execution (ADDGT) branch ko remove kar deta hai, isliye yeh hamesha branch se faster hota hai.

False. Ek skipped conditional instruction phir bhi apna slot NOP ki tarah occupy karta hai (1 cycle). Agar ek branch bahut saari instructions ke upar jump karta, toh branch jeet jaata; conditional execution sirf bahut chote skips ke liye faydemand hota hai.

T/F: ADDGT r1, r1, #1 CPU state ko kuch nahi karta jab condition fail hoti hai.

True (result ke liye), lekin subtle. Jab condition false hoti hai toh instruction NOP ban jaata hai — yeh phir bhi ek cycle occupy karta hai aur fetch/decode hota hai, lekin koi register ya flag write nahi hota.

T/F: ARMv8 (AArch64) ne conditional execution isliye drop kiya kyunki yeh ek buri idea thi.

False. Apne zamaane ke liye yeh ek achha trade-off tha; modern out-of-order cores jisme >95% branch prediction hoti hai, per-instruction conditions ko schedule karna ek well-predicted branch se zyada mushkil paate hain, isliye inhein hatane se hardware simplify hua.

T/F: Zyada deep pipeline (zyada stages) processor ko hamesha faster banati hai.

False. Zyada stages higher clock allow karte hain, lekin ek mispredicted branch ab zyada stages flush karta hai, isliye branch penalty badhti hai — deep pipelines tabhi jeetengi jab prediction achhi ho aur kaam stream ho raha ho.

T/F: AArch64 mein x31 register bas "ek aur general register" hai.

False. x31 context-dependent hai: zyaatar instructions mein yeh zero register ki tarah read hota hai (hamesha 0, writes ignore hote hain), lekin stack-relative contexts mein yeh stack pointer hai. Yeh kabhi ordinary storage register nahi hota.

T/F: Program Counter ARMv7 aur AArch64 dono mein register r15 hai.

False. ARMv7 mein PC r15 hai aur seedha readable/writable hai. AArch64 mein PC ek general register nahi hai — tum ise sirf branches ke through change karte ho.

T/F: Banked registers ka matlab hai FIQ handler user code se zyada total registers ke saath chalta hai.

False. Iske paas same register names hain lekin kuch ke private physical copies hain (jaise r8–r12), isliye handler inhein save/restore nahi karta — faster entry milti hai, zyada registers nahi.

Spot the error

Har snippet ya claim mein ek galti hai. Usse identify karo.

Error? LDR r0, [r1] phir seedha ADD r2, r0, #5 ek simple ARM7 pe.

Data hazard. r0 ka load result tab ready nahi hota jab ADD use chahta hai, isliye pipeline ko stall karna padta hai (ya forward karna) ek cycle — warna ADD stale/not-yet-loaded value read karta.

Error? "Thumb code faster hai kyunki 16-bit instructions half cycles mein execute hote hain."

Galat reason. Thumb instructions per-op faster execute nahi hote; yeh code ko chota banakar jeetengi, jo instruction-cache hit rate badhata hai aur fetch energy ghataata hai.

Error? "Thumb mein tum ARM ki tarah freely saare 16 registers use kar sakte ho."

Galat. Base Thumb mein 3-bit register fields hain, isliye zyaatar instructions sirf r0–r7 tak pahunch sakti hain. Full register access ke liye 32-bit (Thumb-2 ya ARM) encodings chahiye.

Error? "ADD [mem], reg ek normal ARM instruction hai."

ARM mein nahi. Woh memory-destination arithmetic x86 style hai (5.1.10-x86-architecture); ARM isme forbid karta hai load-store rule ki wajah se.

Error? "16 registers isliye choose kiye gaye kyunki programmers ko rarely zyada ki zarurat hoti hai."

Galat driver. Yeh choice ek encoding trade-off hai:

16 = 2^{4}

ek register ko 4 bits mein fit karta hai, fixed 32-bit word mein jagah bachata hai — programmer need ke baare mein koi claim nahi.

Error? "Condition field bits 24–21 mein hoti hai ek data-processing instruction ki."

Galat bits. Condition code bits 31–28 mein hai; bits 24–21 opcode hold karta hai. Inhein mix karne se parallel decode ka poora point toot jaata hai.

Error? "Kyunki ARM RISC hai, isliye har instruction hamesha exactly ek cycle mein khatam hoti hai."

Overstated. RISC ka aim simple, predictable timing hai, lekin loads, stores, aur multi-cycle ops ek se zyada cycle lete hain — "har ek mein ek cycle" ek idealization hai.

Why questions

Reason answer karo, fact nahi.

Load-store design power mein kyun help karta hai, sirf speed mein nahi?

Memory I/O roughly ek register op se 10–100× zyada energy cost karta hai, isliye memory touches ke beech data ko registers mein rakhne se directly energy/instruction ghatti hai — 7.1.05-power-optimization ke liye relevant.

ARM condition aur opcode ko ek saath decode kyun kar sakta hai?

Kyunki fields har 32-bit instruction mein fixed bit positions par hote hain, alag hardware blocks bits 31–28 aur 24–21 ko parallel mein read kar sakte hain — x86 ke serial decode ki tarah pehle length jaanne ki zarurat nahi (5.1.07-ARM-instruction-encoding).

Fixed-width instruction fetch itna simple kyun hai?

Har instruction exactly 4 bytes ki hai, isliye "next instruction" bas

PC + 4

hai — koi variable-length parsing nahi ki ek instruction kahan khatam hoti hai aur agli kahan se shuru.

Conditional execution out-of-order cores ko kyun complicate karta hai?

Condition wali instruction tab tak nahi jaanti ki woh actually commit karegi ya nahi jab tak uske flags pipeline mein late resolve na ho jaayein, jo scheduling aur speculation ko ek cleanly predicted branch se zyada mushkil banata hai (5.2.03-pipelining).

Original ARM7 ne sirf 3-stage pipeline kyun use ki?

Kam stages se per-instruction latency kam hoti hai aur tiny branch penalty milti hai, jo real-time embedded systems ke liye suit karti hai jahan predictable, short response peak clock speed se zyada mayne rakhta hai.

Chota code footprint indirectly speed kyun badhata hai?

Zyada instructions instruction cache mein fit hoti hain, isliye slow DRAM tak kam fetches pahunchti hain — cache hits fast aur cheap hote hain, DRAM fetches slow aur power-hungry hoti hain.

ARM ka licensing model itne varied chips (Apple M-series, AWS Graviton) kyun produce karta hai?

ARM finished chips bechne ki bajay architecture/IP license karta hai, isliye har vendor apne exact workload ke liye ek design fabricate aur tune karta hai ek fixed part use karne ki jagah.

Edge cases

Woh scenarios jo rules almost bhool jaate hain.

MOVLE r2, #0 ka kya hota hai jab compared value ne "Less-or-Equal" ko false banaya?

Yeh ek NOP ban jaata hai — fetch aur decode hota hai, ek cycle consume karta hai, lekin r2 mein kuch nahi likhta aur koi flags touch nahi karta.

CMP internally subtraction use karta hai lekin result kabhi nahi likhta — iska "output" kahan jaata hai?

Condition flags (N, Z, C, V in CPSR/PSTATE) mein. CMP purely flags set karne ke liye exist karta hai ek baad waali conditional instruction ke liye; numeric difference discard ho jaata hai.

Agar ek branch ki prediction accuracy 0% hoti (hamesha galat), kaunsa style jeeega — branches ya conditional execution?

Conditional execution, decisively — har branch pipeline flush kar deta, jabki conditionals sirf kabhi bhi 1-cycle NOP cost karte hain, isliye plausible-mispredict math poori tarah inke favor mein flip ho jaata hai.

AArch64 zero register mein likhne se actually kya hota hai?

Kuch nahi — writes silently discard ho jaate hain, jo "throw-away" destination ke roop mein kaam aata hai jab tumhe instruction ke side effects chahiye (jaise flag setting) lekin result nahi.

3-stage pipeline mein, ek baar full hone ke baad kitni instructions "in flight" hoti hain, aur yeh flush cost ko kyun bound karta hai?

Teen (ek per stage), isliye ek mispredicted branch zyada se zyada couple of cycles waste kar sakta hai — flush cost pipeline depth se bound hoti hai, exactly isliye deep modern pipelines miss pe zyada hurt karte hain.

Kya ek Thumb MOVS instruction condition flags ko unchanged chhod sakta hai?

Design se nahi — trailing S ka matlab hai yeh flags update karta hai; base Thumb data-processing ops automatically flags set karti hain (ARM se ek difference, jahan S suffix optional hai).

Recall Traps ki ek-line summary

Load-store confusion, "fixed-width = chota code", "conditional hamesha branch se jeeega", zero-register/PC-register special cases, aur deeper-pipeline-is-always-faster — yeh paanch ideas hain jo almost sabko pakad leti hain.