Superscalar execution: Question bank — Hinglish deep dive

5.3.1 · D5 · Hardware › Advanced Microarchitecture › Superscalar execution

Ye ek question bank hai Superscalar execution ke liye. Har item ek one-line reveal hai: prompt padho, apna jawab ek reason ke saath zor se bolo, phir check karo. Answer side hamesha reasoning deta hai — sirf "yes/no" bolna intuition banane ke liye bekar hai.

Prerequisites jo dobara padhne chahiye agar koi group mushkil lage: Register Renaming, Tomasulo's Algorithm, Reorder Buffer, Branch Prediction, VLIW Architecture, Cache Hierarchy, Power-Performance Tradeoffs.

Pehle: woh paanch symbols jinpe yeh poora page tikaa hai

Traps try karne se pehle, tumhe IPC limit formulas ka har letter padhna aana chahiye. Inme se koi bhi fancy nahi hai — har ek bas ek count ya fraction hai. Ek baar yahan picture bana lo taaki baad mein koi bhi reveal koi undefined symbol use na kare.

Definition Paanch quantities

Issue width $W$ — kitne instructions front end ek clock cycle mein fetch/decode/dispatch kar sakta hai. "Dispatch" woh moment hai jab ek renamed instruction out-of-order back end ko handover ki jaati hai; fetch/decode/dispatch stages mein jo sabse narrow stage ho woh $W$ set karti hai. $W$ parallel lanes ki highway ki tasveer banao; $W = 4$ matlab har tick mein chaar gaadiyaan daakhil hoti hain.
Functional-unit count $F_{i}$ — execution unit type $i$ ki kitni copies maujood hain (jaise $F_{ALU} = 3$ matlab teen integer adders). Ye woh workers hain jo actual arithmetic karte hain.
Instruction-mix fraction $p_{i}$ — tumhare program mein jo bhi instructions run hoti hain, unka woh fraction jo unit type $i$ ki zaroorat rakhti hain. Agar $30%$ instructions loads/stores hain to $p_{mem} = 0.3$ . Kyunki har instruction exactly ek unit type use karti hai, ye fractions ek complete partition banate hain: $\sum_{i} p_{i} = 1$ .
Reorder-buffer size $ROB$ — Reorder Buffer mein entries ki sankhya, jo circular queue hai aur program order mein in-flight instructions track karti hai. To neeche ke har formula mein " $ROB$ " literally matlab hai kitni instructions machine ek saath in flight rakh sakti hai. Dekho Reorder Buffer.
Dependency length $D$ aur latency $L$ — $D$ ek chain ki average length hai "is instruction ko us wali ka result chahiye, jise kisi aur ka result chahiye..."; $L$ woh cycles hain jo average instruction apna result produce karne mein lagaati hai jab woh start karti hai.

Ye paanch named cheezein hain — ek width $W$ , ek unit-count $F_{i}$ , ek fraction $p_{i}$ , ek buffer size $ROB$ , aur dependency pair $(D, L)$ — aur is page par koi bhi symbol in bahar nahi jaata.

Functional-unit limit $F_{i} / p_{i}$ kyun hota hai

Yahan reasoning hai, sirf formula nahi. Maano tum har cycle mein $x$ instructions retire karna chahte ho. Unka ek fraction $p_{i}$ unit type $i$ ki zaroorat rakhta hai, to un $x$ instructions mein se, $p_{i} \cdot x$ usi cycle mein type- $i$ unit maangte hain. Lekin tumhare paas sirf $F_{i}$ aisi units hain, isliye tum unhe kabhi bhi ek cycle mein $F_{i}$ se zyada serve nahi kar sakte:

$p_{i} \cdot x \leq F_{i} ⟹ x \leq \frac{F _{i}}{p _{i}}$

Isliye units ko fraction se divide karna ek IPC ceiling deta hai: ye hai "kitni total instructions flow ho sakti hain jab tak scarce unit saturate na ho." Kyunki $\sum_{i} p_{i} = 1$ , koi bhi unit type ignore nahi kiya ja sakta — fractions sach mein poore workload tak add hote hain, isliye sabse chhota $F_{i} / p_{i}$ hi asli bottleneck hai. Figure ke sabse baaye panel (Panel 1, titled "Unit limit F/p") dekho — teal memory-demand line $p_{mem} \cdot x$ tab tak upar jaati hai jab tak woh orange worker-count line ko $x = F / p$ par cross nahi karti, woh point jahan woh unit saturate ho jaati hai.

Dependency limit $\frac{W \cdot ROB}{D \cdot L}$ kyun hota hai

Ise teen "kyun" steps mein banao.

$ROB$ upar kyun? Reorder buffer mein ek waqt mein zyada se zyada $ROB$ instructions in flight hoti hain, isliye ye woh window ka size hai jisme hardware independent work dhoondh sakta hai. Badi window zyada parallelism expose karti hai.

$D \cdot L$ se kyun divide karte hain? Length $D$ ki ek single dependency chain ek waqt mein ek link se zyada fast nahi ja sakti, aur har link apna result produce karne mein $L$ cycles leta hai — to poori chain $D \cdot L$ cycles mein khatam hoti hai. Isi dauran $ROB$ instructions ki window mein lagbhag $ROB / D$ independent chains side by side hoti hain. Woh independent chains interleave karti hain: jab chain A $L$ cycles wait karti hai apne link ke khatam hone ka, lanes chains B, C, D, ... run karti hain. To $D \cdot L$ cycles mein jo window drain hone mein lagti hai, usme roughly $ROB$ instructions complete hoti hain — rate $\frac{ROB}{D \cdot L}$ instructions per cycle hai.

$W$ se kyun multiply karte hain? Woh rate woh hai jo back end sustain kar sakta hai, lekin instructions abhi bhi front end se guzarni padti hain. Har cycle front end zyada se zyada $W$ nayi instructions inject kar sakta hai window ko refill karne ke liye jaise woh drain hoti hai. Agar back end principle mein $W$ per cycle se fast drain kar sakta, to front end use throttle kar deta — isliye $W$ multiply karta hai (cap karta hai) interleaving window ko refill karna. Hence $\frac{W \cdot ROB}{D \cdot L}$ .

Common mistake "Latency

$L$ " secretly kya bundle karta hai — aur uske edge cases Steady-state formula average latency $L$ aur dependency length $D$ ke andar saare stall sources chhupaa deta hai. Do bade wale apni alag accounting deserve karte hain:

Load misses $L$ ko inflate karte hain: ek normal load ka $L \approx 3$ – $4$ hota hai; ek L2 ya main-memory miss us single instruction ki effective latency ko $20$ – $300$ cycles tak push kar sakta hai (dekho Cache Hierarchy). Ye wahi $L$ nahi hai jaise ek add ka — ek miss ko local spike $L_{miss}$ maano, aur machine ise tabhi chhupaa sakti hai jab ROB window mein independent work baaki ho.
Branch mispredicts $L$ mein fit nahi hote — ye $D$ ko feed karte hain aur poori window waste karte hain. Ek mispredict speculatively fetched instructions ko flush kar deta hai aur fetch restart kar deta hai, effectively interleaving window reset kar deta hai; ise per-mispredict penalty $P_{mp}$ cycles times mispredict rate model karo, useful throughput se ghataate hue (dekho Branch Prediction).

Sabak ye hai: jab bhi koi kahe "bas $L$ badha do", poochho kaun sa stall — ek memory spike alag behave karta hai ek control-flow flush se, aur dono ko ek average $L$ mein lump karna exactly woh edge cases chhupaa deta hai jo neeche ke exercises probe karte hain.

Middle panel (Panel 2, titled "Dependency limit") dikhata hai ek full window ek dependent chain of length $D$ drain karte hue: har teal/plum block us par depend karne ke $L$ cycles baad execute karta hai, aur orange arrows "is wali ka result chahiye" ke links hain — chain jitni lambi, utne zyada doosre lanes idle rehte hain.

True ya false — justify karo

Ek pipelined processor aur ek superscalar processor ek hi cheez hain

False. Ek plain pipeline mein har stage mein ek instruction hoti hai — ye instructions overlap karti hai lekin phir bhi har cycle mein zyada se zyada ek start aur finish karti hai; ek superscalar mein multiple parallel lanes hoti hain isliye ye har cycle mein kayi start aur retire kar sakta hai.

Ek 4-wide superscalar hamesha 4 IPC achieve karta hai

False. 4 ceiling hai (fetch/decode/dispatch width

W

); asli IPC us width, functional-unit limits

F_{i} / p_{i}

, aur dependency limit ka minimum hai — koi bhi ek ise 4 se kaafi neeche gira sakta hai.

Out-of-order execution ka matlab hai ki instructions retire bhi out of order hoti hain

False. Instructions out of order execute hoti hain lekin Reorder Buffer unhe program order mein commit karne par majboor karta hai, jo precise exceptions preserve karta hai.

False. RAW ek true data dependency hai — reader sach mein woh value chahiye jo likhi ja rahi hai — isliye koi renaming use nahi hata sakta; renaming sirf false WAW aur WAR hazards khatam karta hai.

Renaming WAW hazards is tarah remove karta hai ki dono writes ek saath hoti hain

False. Ye unhe is tarah remove karta hai ki dono writes alag physical registers par jaati hain, isliye unka order ab matter nahi karta — kuch bhi simultaneously hone par force nahi kiya jaata.

Zyada functional units add karna hamesha IPC badhata hai

False. Extra units ek single

F_{i} / p_{i}

term uthate hain, isliye ye tabhi help karte hain jab woh term sabse chhota ho; agar width

W

ya dependency limit bottleneck tha, to nayi units idle rehti hain.

Ek bada reorder buffer performance mein sirf help kar sakta hai, kabhi hurt nahi

Practically mostly false. Bada ROB dependency ceiling

W \cdot ROB / (D \cdot L)

uthata hai, lekin area, ports, aur power lagta hai aur search logic lambi ho jaati hai — ek classic power–performance tradeoff jahan zyada silicon diminishing IPC kharidta hai.

Agar har instruction pichli par depend karti hai, to ek 8-wide superscalar 1-wide ki tarah behave karta hai

True. Fully serial chain

D

ko program length ke barabar karta hai, isliye dependency limit

W \cdot ROB / (D \cdot L)

1 ke paas collapse hoti hai chahe machine kitni bhi wide ho.

VLIW aur superscalar instruction-level parallelism ek hi tarah solve karte hain

False. VLIW Architecture compiler ko allow karta hai ki woh independent ops ko ek wide word mein pack kare (static scheduling); superscalar hardware renaming aur reservation stations ke zariye run time par parallelism dynamically discover karta hai.

Ek superscalar ek cache miss chhupaa sakta hai jab tak uske ROB mein free entries hain

Partly true. Ye miss resolve hote waqt independent work issue karta rehta hai, lekin missing load ROB head par baithkar retirement block karta hai; jab ROB bhar jaata hai, dispatch stall kar deta hai chahe width kuch bhi ho — ek miss

L

mein local spike hai jo eventually cache-fed window drain kar deta hai.

Error dhundho

"Hum 4 per cycle fetch karte hain, isliye 4 per cycle retire karte hain."

Galat link: fetch width

W

input rate bound karta hai, lekin retirement us instruction se bound hoti hai jo stuck hai (slow load, dependency, ya full unit); average retire rate ≤ fetch rate, aksar strictly less.

"Kyunki renaming har write ko apna physical register deta hai, isliye registers kabhi khatam nahi hote."

Galat: physical register file finite hai; jab woh khaali ho jaati hai, rename stall karni padti hai jab tak koi in-flight instruction retire na ho aur apna purana physical register free na kare — Register Renaming pool bhi koi aur resource ki tarah hai.

"Instruction mix 60% memory hai aur hamare paas 2 load/store units hain, isliye memory throughput

2 \times 0.6 = 1.2

IPC hai."

Galat formula: memory limit

F_{i} / p_{i} = 2/0.6 \approx 3.33

IPC hai (units divided by fraction jo unhe chahiye), units times fraction nahi.

"Branches sirf ek aur instruction type hain; ye superscalar width utilization affect nahi karte."

Galat: ek mispredicted branch apne peeche speculatively fetched saari instructions flush kar deta hai, isliye Branch Prediction accuracy directly cap karti hai ki width

W

ka kitna hissa actually useful hai.

"Ek micro-op cache fetch width raise karta hai, isliye theoretical IPC ceiling raise karta hai."

Do confusions. Pehli, micro-op cache decode ke baad hoti hai — ye already-decoded micro-ops store karti hai taaki pipeline ek hit par fetch-and-decode skip kar sake, decode bottleneck (x86 variable-length boundary-finding) ease karke aur power bachake, raw fetch widening nahi. Doosri, ceiling

W

fetch/decode/dispatch mein sabse narrow se set hoti hai; dispatch (rename + reservation stations ko hand-off) usually asli limiter hota hai, aur micro-op cache ise wider nahi karta.

"Do instructions jo ek hi architectural register mein write karte hain kabhi parallel nahi chal sakti."

Galat: renaming ke baad ye alag physical registers mein write karte hain, isliye ye parallel chal sakti hain; sirf RAT mein mapping record karni padti hai ki kaun 'latest' hai.

"128-entry ROB aur average latency 2 ke saath, dependency limit 128/2 = 64 IPC hai."

Terms missing hain: limit

\frac{W \cdot ROB}{D \cdot L}

hai; tumne numerator mein width

W

aur denominator mein dependency length

D

chod di.

Why questions

Program order mein retirement kyun zaruri hai chahe execution na ho?

Taaki ek exception par har pichli instruction commit ho chuki ho aur koi baad wali visible effect na chhod chuki ho — precise exception guarantee jo OS rely karta hai.

Variable-length x86 encoding wide decode ko khaas taur par mushkil kyun banata hai?

Tum instruction 2 ka start tab tak nahi jaante jab tak instruction 1 ki length nahi pata, isliye parallel boundary-finding ko pre-decode bits ya complex speculative decoders chahiye.

Tomasulo's Algorithm decode directly execution par karne ki jagah reservation stations kyun use karta hai?

Reservation stations instructions hold karti hain aur apne operands ke liye result bus snoop karti hain, ek instruction ko apna data wait karne deti hain bina program order mein peeche waalon ko block kiye.

Wide fetch bina achhe branch predictor ke useless kyun hai?

Real code roughly har 5–7 instructions mein branch karta hai, isliye branches ke paas prediction ke bina tumhare paas rarely itni consecutive instructions hogi ki width

W

ki wide fetch window fill ho sake.

IPC formula saare limits par min kyun leta hai average ki jagah?

Throughput tightest constraint set karta hai — sabse slow stage ya scarcest resource — isliye

W

min_{i} F_{i} / p_{i}

aur dependency limit mein sabse bura govern karta hai, exactly jaise pipe ka sabse narrow section uska flow set karta hai.

Renaming WAR (anti-dependency) hazards kyun eliminate kar sakta hai?

Baad wali write ek fresh physical register par redirect hoti hai, isliye woh woh value overwrite nahi kar sakti jo pehli wali read ko abhi bhi chahiye — dono ab alag storage touch karte hain.

Cache misses aur branch mispredicts dono ko ek "average latency

L

" mein chhupana kyun dangerous hai?

Ek load miss

L

locally inflate karta hai lekin chhupaya ja sakta hai jab tak independent work rahe; ek mispredict poori window flush kar deta hai aur fetch reset kar deta hai — dono ko ek

L

se model karna us alag behaviour aur edge cases ko erase kar deta hai jo ye create karte hain.

Edge cases

Ek superscalar ka IPC kya hai jo ek single long chain of dependent adds run kar raha hai (D = N)?

Roughly 1 — bade

D

ke saath dependency limit

W \cdot ROB / (D \cdot L)

1 ke paas aa jaati hai, kyunki har add pichle result ka wait karta hai aur extra lanes waste hote hain.

Ek 4-wide machine ka kya hota hai agar ek bundle ki saari chaar instructions ek FP-divide unit chahti hain?

Structural hazard:

F_{i} = 1

isliye ek hi us cycle mein issue hoti hai jabki baaki teen reservation stations mein wait karti hain — ye bundle us unit par 1 IPC achieve karta hai chahe width kuch bhi ho.

Kya hoga agar instruction mix mein kisi unit type ke liye

p_{i} = 0

ho?

Woh unit koi limit nahi laagti —

F_{i} / p_{i}

jab

p_{i} = 0

hai to "infinite headroom" hai, isliye tum us term ko min mein drop karte ho na ki compute karte ho; baaki fractions phir bhi 1 tak sum hoti hain.

Maximum in-flight instruction count kya hai, aur use kya cap karta hai?

Ye ROB size ke barabar hota hai; jab reorder buffer full ho jaata hai, dispatch stall kar deta hai chahe functional units idle hoon, kyunki nayi instruction ka ordering kahin track nahi ho sakti.

Full ROB wale ek superscalar ko straight-line, fully-independent code par kya limit karta hai?

Akela fetch/decode/dispatch width

W

— koi dependencies (

D \approx 1

) nahi aur koi unit shortage nahi matlab min IPC ko front-end width par pin karta hai, formula ka best case.

Ek full ROB mein deep branch mispredict par kya hota hai?

Branch ke baad ki saari instructions squash ho jaati hain aur RAT branch ki mapping par roll back ho jaata hai; speculation jitni deep hoti hai, utna zyada kaam faika jaata hai — ek per-mispredict penalty

P_{mp}

useful throughput se ghataaya jaata hai, aur aggressive Branch Prediction ki ek key cost.

Recall Jaane se pehle do-line self-test

Fetch vs retire — kaun kaun ko bound karta hai, aur picture karo kyun? ::: Fetch width $W$ highway ka entrance hai; retire exit hai, sabse slow stuck car se throttle hota hai (cache-missed load, dependency, saturated unit). Sustained IPC = exit rate ≤ entrance rate $W$ , aur usually strictly less kyunki koi na koi lane hamesha wait kar rahi hai. IPC min ke andar teeno terms, aur har ek ki mental image? ::: Width $W$ = highway lanes; $min_{i} F_{i} / p_{i}$ = sabse scarce toll booth (workers ÷ demand-fraction, aur fractions 1 tak sum hoti hain); $\frac{W \cdot ROB}{D \cdot L}$ = ROB window length $D$ ki chains ke against kitna independent work expose kar sakta hai. Teeno mein sabse narrow flow set karta hai.