Register renaming: Worked examples — Hinglish deep dive

5.3.4 · D3 · Hardware › Advanced Microarchitecture › Register renaming

Yeh page Register renaming ki hands-on drill hai. Parent note ne tumhe algorithm aur ek clean example diya tha. Yahan hum deliberately har awkward case dhundte hain: false hazards, real hazards jo tum tod nahi sakte, woh moment jab free list khaali ho jaati hai, woh branch jo mispredicted hoti hai, aur woh exception jo rollback force karti hai. Agar tum yeh sab haath se trace kar sako, toh renaming samajh gaye.

Upar wali figure woh map hai jis par hum har worked example mein wapas aate hain. Isse left se right padho aur iske teen arrows yaad karo, kyunki har example unhe ek specific order mein fire karta hai:

Arrow ①, cyan "read sources": RAT ko consult kiya jaata hai taaki pata chale current source values kahan hain.
Arrow ②, amber "allocate": Free list se ek slot nikalta hai jo destination ka naya $P_{n e w}$ banta hai; usi waqt RAT ki purani mapping ROB mein copy hoti hai (arrow par "record old" ka tick).
Arrow ③, amber "commit frees old": Ek committed (ya squashed) instruction apna $P_{o l d}$ Free list ko wapas karta hai.

Toh ek normal instruction ka uniform pattern hai ① read → ② allocate + record → (baad mein) ③ free. Jab koi example neeche "read / allocate+record / free" kahe, toh is figure par wapas jhaanko aur dekho kaunsa arrow fire ho raha hai.

Symbols se pehle, ek vocabulary check taaki kuch bhi unexplained na rahe:

Definition Teen hazard ke naam (RAW, WAR, WAW)

Hazard tab hota hai jab do instructions ek hi register name ko touch karti hain aur unka order achanak important ho jaata hai. Inhe literally "second-thing After first-thing" padho toh yaad rehte hain:

RAW — Read After Write. Baad wali instruction ek register padhti hai jo pehle wali ne likha tha. Yeh true dependency hai: reader ko genuinely producer ki value chahiye. Renaming isse preserve karti hai.
WAR — Write After Read. Baad wali instruction ek register likhti hai jo pehle wali abhi padhna chahti thi. Yeh false hai: writer ko reader ki value ki zaroorat nahi, bas naam reuse ho gaya. Renaming isse hata deti hai.
WAW — Write After Write. Do instructions ek hi register naam likhti hain. Yeh bhi false hai: architectural state sirf yahi care karta hai ki aakhiri write kaun si thi. Renaming isse hata deti hai. Renaming ki poori kala yeh hai: RAW rakhho, WAR aur WAW hatao.

Scenario matrix

Har renaming problem inhi cells se banti hai. Baad ke worked examples label kiye gaye hain us cell ke saath jo woh cover karte hain, aur milke sab ko hit karte hain. (RAW/WAR/WAW upar define hain.)

#	Case class	Kya special hai	Agar galat karo toh khatre
A	RAW (true)	reader ko real result chahiye	isse rename nahi karna — link rakho
B	WAR (anti)	writer ek aisa naam reuse karta hai jo abhi bhi read ho raha hai	destination rename karo → hazard gaayab
C	WAW (output)	do writes ek hi naam par	har ek rename karo → last wala sahi jeete
D	Read-before-any-write	source kabhi rename nahi hua	initial mapping padhni hai
E	Chained RAW	ek ka dest doosre ka source hai	naya physical tag propagate hona chahiye
F	Free list empty	allocate karne ko koi physical register nahi	decode stall kare (register pressure)
G	Commit frees old	in-order commit ek slot wapas karta hai	old $P$ free karo, new wala nahi
H	Branch mispredict	wrong-path instructions renamed ho gayi	checkpoint se RAT restore karo
I	Exception rollback	instruction mid-flight mein fault kare	ROB unwind karo, old mappings restore karo
J	Degenerate: dest = source	jaise `ADD R1,R1,R2`	pehle old $P$ padho phir new $P$ allocate karo

Hum poore mein 9 architectural registers R1–R9 aur physical registers P0–P31 use karte hain, is starting state ke saath (parent ki extension — parent ne R1–R8 use kiye; R9 add kiya taaki SUB examples ka ek valid second source ho):

Worked examples

Example 1 — Pure RAW chain (cells A, D, E)

Worked example Statement

Shared initial state se rename karo:

I1: ADD R1, R2, R3   # R1 = R2 + R3
I2: MUL R4, R1, R5   # R4 = R1 * R5

Har instruction ke baad RAT do, har instruction ka ROB entry do, aur jo physical-register operation execute hui woh bhi do.

Forecast: I2 R1 ke liye kaunsa physical register read karega — purana P10 ya naya wala? Padhne se pehle guess karo.

Step 1 — RAT se I1 ke sources padho (arrow ①). $RAT [R 2] = P 11$ , $RAT [R 3] = P 12$ . Yeh step kyun? (cell D) R2 aur R3 abhi tak kabhi likhe nahi gaye, toh unki values initial slots mein hain. Guess mat karo — hamesha current table lookup karo.

Step 2 — R1 ke liye fresh destination allocate karo, aur old mapping record karo (arrow ②). Free list se $P 0$ pop karo. Current $RAT [R 1] = P 10$ ko $P_{o l d}$ ke roop mein capture karo, phir ROB[0]={R1, old P10, new P0} likho. $P 0 \leftarrow P 11 + P 12$ execute karo. Yeh step kyun? R1 ko apna khud ka slot chahiye (P10 reuse karne se kisi ki still-read value clobber ho sakti thi), aur ROB mein old mapping P10 abhi stamp karni hai — yeh wahi akaila record hai jo hame P10 commit par free karne ya fault par restore karne deta hai.

Step 3 — RAT update karo: $R 1 \to P 0$ . Yeh step kyun? Aage R1 padhne wali har instruction ko ab naya result milna chahiye.

Step 4 — I2 ke sources padho (arrow ①). $RAT [R 1] = P 0$ (P10 nahi!), $RAT [R 5] = P 14$ . Yeh step kyun? (cells A, E) Yeh true RAW dependency hai. Step 3 ne already R1 ko P0 par redirect kar diya, toh I2 automatically I1 ka result padhta hai. Dependency preserve hoti hai, hatayi nahi — yahi RAW ka poora point hai.

Step 5 — R4 ke liye allocate karo, record karo, execute karo (arrow ②). $P 1$ pop karo; $RAT [R 4] = P 13$ capture karo aur ROB[1]={R4, old P13, new P1} likho; $P 1 \leftarrow P 0 \times P 14$ execute karo; $R 4 \to P 1$ set karo. Yeh step kyun? R4 likha ja raha hai, toh usse apna fresh slot P1 chahiye, uski old mapping P13 record honi chahiye, aur R4 ke aage ke reads wahan redirect hone chahiye.

Verify: Renaming ke baad, R1 P0 mein hai, R4 P1 mein. I2 ka pehla source P0 hai, exactly I1 ka destination — I1 se I2 tak data path exist karta hai, RAW link intact. ROB mein {R1,P10,P0} aur {R4,P13,P1} hain, woh do old mappings jo baad mein kaam aayengi. ✓

Example 2 — WAR aur WAW dissolve hue (cells B, C, G)

Worked example Statement

Example 1 ko continue karo yeh instructions ke saath:

I3: ADD R1, R6, R7   # R1 = R6 + R7   (WAW I1 ke saath, WAR I2 ke saath)
I4: SUB R8, R1, R9   # R8 = R1 - R9   (RAW I3 ke saath)

Dikhao ki I3 I2 finish hone se pehle run kar sakta hai, uska ROB entry record karo, phir dikhao ki commit kya free karta hai.

Forecast: I3 ke baad, kya I2 abhi bhi correct old R1 padhega? Haan/Nahi — abhi decide karo.

Step 1 — I3 ke sources padho (arrow ①). $RAT [R 6] = P 15$ , $RAT [R 7] = P 16$ . Kisi ne R6/R7 nahi chua, toh initial slots. Yeh step kyun? Compute karne se pehle hame pata karna hai ki current R6 aur R7 values kahan hain; unhe kabhi rename nahi kiya gaya, toh initial mapping abhi bhi valid hai.

Step 2 — P2 allocate karo, old record karo, execute karo (arrow ②). P2 pop karo; $RAT [R 1] = P 0$ capture karo aur ROB[2]={R1, old P0, new P2} likho; $P 2 \leftarrow P 15 + P 16$ execute karo. Yeh step kyun? (cells B, C) I3 R1 likhta hai, I1 ne bhi likha tha (WAW), jabki I2 abhi bhi R1 padh raha hai (WAR). Brand-new slot P2 mein likhne se I3 kisi se bhi clash nahi karta: I2 P0 padhta rehta hai, I3 P2 likhta hai. ROB mein old-P0 record karna wahi hai jo baad mein commit ko P0 safely free karne dega.

Step 3 — RAT update karo: $R 1 \to P 2$ . Yeh step kyun? Ab se, R1 padhne wali koi bhi instruction I3 ka result dekhni chahiye, toh naam R1 ko P2 point karna chahiye. I2 ne already Example 1 step 4 mein P0 capture kar liya tha, toh naam redirect karna use disturb nahi karta.

Step 4 — I4: padho, allocate karo, record karo, execute karo (arrows ① phir ②). $RAT [R 1] = P 2$ padho, $RAT [R 9] = P 18$ ; P3 pop karo; ROB[3]={R8, old P17, new P3} likho; $P 3 \leftarrow P 2 - P 18$ execute karo; $R 8 \to P 3$ set karo. Yeh step kyun? (cell A) I4 ka I3 par RAW real hai; P2 padhna isse preserve karta hai, R8 ki write ko fresh slot P3 chahiye, aur P17 uski old mapping ke roop mein record hoti hai.

Step 5 — Program order mein I1 commit karo (arrow ③). I1 ki entry hai ROB[0]={R1, old P10, new P0}. P10 ko free list mein push karo. Yeh step kyun? (cell G) Woh register free karo jo destination pehle point karta tha, kyunki ab program order mein koi bhi P10 nahi padhega. P0 free mat karo — I2 abhi bhi use karta hai, aur I3 ka ROB entry abhi bhi P0 ko apni old mapping ke roop mein name karta hai.

Verify: Physical slots use huye: I1→P0, I2→P1, I3→P2, I4→P3, sab alag. I2 P0 padhta hai, I3 P2 likhta hai → WAR gone. I1 aur I3 P0 aur P2 likhte hain → WAW gone. ROB mein ab chaar entries hain; I1 commit karna exactly P10 (uska $P_{o l d}$ ) free karta hai, P0 nahi. ✓

Example 3 — Degenerate: destination equals source (cell J)

Worked example Statement

Shared initial state se rename karo:

I1: ADD R1, R1, R2   # R1 = R1 + R2

Yeh trap hai. Kya steps ka order matter karta hai?

Forecast: agar tum pehle new physical register allocate karo, toh kya galat ho jaayega?

Step 1 — Pehle source R1 padho (arrow ①). $RAT [R 1] = P 10$ . Aur $RAT [R 2] = P 11$ . Yeh step kyun? (cell J) R1 source bhi hai aur destination bhi. Read ko purani mapping P10 capture karni hai overwrite se pehle. Order ulta karne par instruction apna abhi-tak-compute-na-hua result padh leti.

Step 2 — Destination allocate karo aur old record karo (arrow ②). $P 0$ pop karo; ROB[0]={R1, old P10, new P0} likho; $P 0 \leftarrow P 10 + P 11$ execute karo. Yeh step kyun? Source read safely capture hone ke baad hi fresh slot diya ja sakta hai; note karo ki recorded $P_{o l d} = P 10$ exactly wahi value hai jo humne abhi source ke roop mein padhi — ROB entry aur source read construction se agree karte hain.

Step 3 — RAT update karo: $R 1 \to P 0$ . Yeh step kyun? Naam R1 ko ab P0 mein nayi computed result point karni chahiye, taaki baad mein R1 ka har reader updated value dekhe na ki stale P10.

Verify: Source read = P10 (pre-instruction R1), destination = P0, ROB old P10 record karta hai. Instruction old R1 ko R2 se jodhke fresh slot mein daalta hai — yeh R1_new = R1_old + R2 jaisa hi hai. Agar pehle allocate karte aur baad mein padhte, toh R1 P0 (uninitialised) padh leta — yeh bug hota. Read-then-allocate mandatory hai. ✓

Example 4 — Free list empty: register pressure stall (cell F)

Worked example Statement

Maano sirf do physical registers free hain: free list = $[P 0, P 1]$ , aur ROB un-committed instructions se otherwise bhara hua hai. Is stream ko rename karo (poora read / allocate+record bookkeeping):

I1: ADD R1, R2, R3
I2: MUL R4, R5, R6
I3: SUB R7, R1, R4

I3 par kya hota hai?

Forecast: kuch block hone se pehle kitni instructions rename hoti hain?

Step 1 — I1: padho, allocate karo, record karo (arrows ① phir ②). $RAT [R 2] = P 11$ , $RAT [R 3] = P 12$ padho; P0 pop karo (free list → $[P 1]$ ); ROB[k]={R1, old P10, new P0} likho; $R 1 \to P 0$ set karo. Yeh step kyun? Pressure mein bhi bookkeeping unchanged hai: sources pehle padhe jaate hain, phir destination top free slot consume karta hai aur apni old mapping ROB mein stamp karta hai.

Step 2 — I2: padho, allocate karo, record karo (arrows ① phir ②). $RAT [R 5] = P 14$ , $RAT [R 6] = P 15$ padho; P1 pop karo (free list → $[]$ , empty); ROB[k+1]={R4, old P13, new P1} likho; $R 4 \to P 1$ set karo. Yeh step kyun? I2 R4 likhta hai, aakhiri free slot P1 consume karta hai aur old-P13 record karta hai; free list ab khaali hai, yahi woh condition hai jo hum stress-test karna chahte hain.

Step 3 — I3: read succeed karta hai, allocate FAIL karta hai. $RAT [R 1] = P 0$ , $RAT [R 4] = P 1$ padho (arrow ① fine complete hota hai). Phir arrow ② attempt karo: free list khaali hai → decode stalls. Yeh step kyun? (cell F) Sources padhne ke liye koi free slot nahi chahiye, toh arrow ① hamesha kaam karta hai. Lekin har write ko arrow ② ke liye ek fresh physical slot chahiye. Koi available nahi hone par renamer valid ROB entry record nahi kar sakta aur forward progress nahi kar sakta; I3 decode mein wait karta hai. Yahi exactly register pressure hai.

Step 4 — Ek purani instruction commit karti hai (arrow ③), phir I3 resume karta hai. Ek committed instruction apna $P_{o l d}$ (maano P10) wapas push karti hai: free list → $[P 10]$ . Ab I3 arrow ② complete karta hai: P10 pop karo, ROB[k+2]={R7, old P16, new P10} likho, $R 7 \to P 10$ set karo. Yeh step kyun? Commit exactly ek $P_{o l d}$ wapas karta hai; woh ek slot stalled I3 ko allocate, apni old mapping (P16) record karne, aur aage badhne deta hai.

Verify: Do allocations ek do-entry free list exhaust karte hain ( $2 - 2 = 0$ ), toh teesre ka arrow ② stall karta hai even though uska arrow ① read (P0, P1) succeed hua. Ek commit exactly ek slot restore karta hai, exactly ek aur allocation enable karta hai, jiska ROB entry {R7, old P16, new P10} hai. Stall pipeline ka khud ko physical-register budget tak throttle karna hai. ✓

Example 5 — Branch misprediction rollback (cell H)

Example se pehle, ek mechanism define karna zaroori hai taaki recovery hand-waved na lage:

Worked example Statement

I1: ADD R1, R2, R3       # R1 ke liye P0 allocate karta hai
I2: BEQ R1, R2, target   # branch: taken agar R1 == R2; predicted NOT taken
I3: MUL R4, R1, R5       # wrong-path agar branch WAS taken
I4: ADD R1, R6, R7       # wrong-path

Branch mispredicted thi (actually taken). I3, I4 wrong path par rename hue. Machine restore karo.

Forecast: recovery ke baad R1 kya map karta hoga — woh jo I3/I4 se pehle tha, ya baad mein?

Shared initial state se shuru karo aur pehle I1 aur I2 rename karo:

I1 R1 ke liye P0 pop karta hai, {R1, old P10, new P0} record karta hai; free list $[P 1, P 2, P 3, \dots]$ ban jaati hai.
I2 branch hai: BEQ R1 aur R2 padhta hai lekin kuch likhta nahi, toh koi physical register allocate nahi hota. Free list $[P 1, P 2, P 3, \dots]$ rehti hai. Is branch par checkpoint lete hain: $R 1 \to P 0$ , $R 4 \to P 13$ , baaki sab initial.

Step 1 — I3 ko speculatively rename karo (arrows ① phir ②). $RAT [R 1] = P 0$ , $RAT [R 5] = P 14$ padho; P1 pop karo (free list → $[P 2, P 3, \dots]$ ); {R4, old P13, new P1} record karo; $R 4 \to P 1$ set karo. Yeh step kyun? Branch ka outcome unknown hone par bhi, pipeline predicted path par rename karte rehti hai taaki kabhi idle na rahe; I3 current R1 (P0) padhta hai aur R4 ke liye next free slot P1 leta hai.

Step 2 — I4 ko speculatively rename karo (arrows ① phir ②). $RAT [R 6] = P 15$ , $RAT [R 7] = P 16$ padho; P2 pop karo (free list → $[P 3, \dots]$ ); {R1, old P0, new P2} record karo; $R 1 \to P 2$ set karo. Yeh step kyun? Speculatively continue karte hue, I4 R1 ko fresh slot P2 mein likhta hai; yeh woh RAT change hai jo undo karna padega agar guess galat nikla.

Step 3 — Branch resolve hoti hai: mispredict. I3 aur I4 squash hone chahiye. Yeh step kyun? (cell H) Unhe execute hi nahi hona chahiye tha. Unke kiye RAT changes aur allocations wrong-path pollution hain.

Step 4 — Checkpoint se RAT restore karo; wrong-path slots free karo (arrow ③). Checkpoint wapas copy karo: $R 1 \to P 0$ , $R 4 \to P 13$ . P1 aur P2 free list mein wapas karo. Yeh step kyun? Checkpoint ne exactly woh map capture kiya tha jab speculation shuru hoi thi, toh wapas copy karne se saare wrong-path changes ek step mein mit jaate hain; do speculatively-allocated slots pool mein wapas jaate hain.

Verify: I1 ke baad, sirf P0 gaya hai, toh branch par free list $[P 1, P 2, \dots]$ hai — wrong-path instructions isliye P1 aur P2 lete hain (P2/P3 nahi). Recovery ke baad $R 1 \to P 0$ (I1 ka result) aur $R 4 \to P 13$ (committed value); freed slots exactly ${P 1, P 2}$ hain. Physical-register count conserved hai. ✓

Example 6 — Exception rollback via ROB (cell I)

Step 1 — I2 se puraani har cheez commit karo (arrow ③). I1 normally commit karta hai: uski entry {R1, old P10, new P0} old P10 free karta hai. Yeh step kyun? (cell I) Precise exception faulting instruction se pehle ki saari instructions preserve karta hai. I1 cleanly finish hua, toh retire karta hai aur apna $P_{o l d}$ wapas karta hai.

Step 2 — I2 par fault lo; tail se I2 tak ROB unwind karo (arrow ③, reverse mein). Reverse program order mein entries I4, I3, I2 walk karo, har ek $P_{o l d}$ restore karo aur har ek $P_{n e w}$ free karo:

I4 {R8,P17,P3} undo karo: $R 8 \to P 17$ set karo, P3 free karo
I3 {R1,P0,P2} undo karo: $R 1 \to P 0$ set karo, P2 free karo
I2 ki khud ki entry {R4,P13,P1} undo karo: $R 4 \to P 13$ set karo, P1 free karo

Yeh step kyun? Tail se unwind karne se mappings reverse order mein restore hoti hain, toh har register wahan wapas jaata hai jahan uska writer run karne se pehle point karta tha. $P_{n e w}$ slots jo squashed instructions ne allocate kiye the, free ho jaate hain kyunki koi bhi inhe valid taur par nahi padhega. Yahi har example mein stamp kiye "record old" arrow ② ka payoff hai — un recorded $P_{o l d}$ fields ke bina yeh reversal impossible hota.

Step 3 — Resulting architectural state. $R 1 \to P 0$ (committed I1 se), $R 4 \to P 13$ , $R 8 \to P 17$ ; free list P1, P2, P3 wapas paata hai (plus step 1 se P10). Yeh step kyun? Yeh exact machine state hai jaise sirf I1 run hua ho — precise ka definition.

Verify: I1 ki write survive karti hai ( $R 1 \to P 0$ ), jabki I2/I3/I4 gaayab ho jaate hain ( $R 4 \to P 13$ , $R 8 \to P 17$ ). Unwinding se freed: P1, P2, P3 — exactly woh teen jo squashed instructions ne allocate kiye the; plus I1 commit karne se P10. ROB ka old-mapping field exactly wahi hai jo reversal possible banata hai. ✓

Example 7 — Cycle-count word problem (real-world twist)

Numbers se pehle, woh timing vocabulary jo yeh example use karta hai:

Step 1 — Ratio likho. $Speedup = \frac{T _{without}}{T _{with}} = \frac{9}{6} .$ Yeh step kyun? Speedup hai old time divided by new time — ek dimensionless number jo batata hai kitna zyada fast.

Step 2 — Evaluate karo. $9/6 = 1.5$ . Yeh step kyun? Fraction reduce karne se plain multiplier milta hai; $9$ aur $6$ mein $3$ common factor hai, toh $9/6 = 3/2 = 1.5$ .

Step 3 — Interpret karo. Renaming ne R1 par false WAR/WAW stalls hata diye, I3 ko I2 ke saath saath start karne diya I2 ke baad ki jagah. Yeh step kyun? Number ka poora point hai usse ek mechanism se attribute karna — yahan eliminated false dependencies exactly wahi hain jo without-renaming timeline se "wait" cycles shrink karte hain.

Verify: $1.5 \times$ matlab renamed block $6/9 = 0.667$ original time mein finish hota hai. Cycles dono top aur bottom par unit hain, toh speedup unitless hai. ✓

Example 8 — Physical-register sizing (exam-style)

Step 1 — (a) Sizing bound apply karo. $N_{p h y s} \geq N_{a r c h} + N_{R O B} = 16 + 224 = 240.$ Yeh step kyun? Tumhe ek slot chahiye har committed architectural value ke liye (16) plus ek har in-flight, uncommitted instruction ke liye jisne slot allocate kiya ho (up to 224). 240 se neeche, ek full ROB ek aisa slot demand kar sakta hai jo file supply nahi kar sakti.

Step 2 — (b) Design-friendly number par round karo. $240$ se bada ya equal next power of two hai $256 = 2^{8}$ . Yeh step kyun? Physical registers binary tag se address hote hain; power of two choose karna woh tag ek clean fixed width ka banata hai (yahan 8 bits) bina wasted decode logic ke, toh designers woh chhota power of two choose karte hain jo abhi bhi minimum meet kare.

Step 3 — (b, continued) Report karo aur justify karo. Minimum 240, typical 256, 8-bit physical register tag use karte hue. Extra $256 - 240 = 16$ slots useful slack hain: woh back-to-back writes ke bursts ko bina immediately Example 4 ke register-pressure stall hit kiye allocate karne dete hain. Yeh step kyun? Exam answer mein dono hard minimum aur practical choice name honi chahiye, aur explain karo ki choice woh tightest power-of-two hai jo cleanly index bhi kare aur headroom bhi rakhe.

Verify: $2^{8} = 256 \geq 240$ , aur $2^{7} = 128 < 240$ bahut chhota hota — toh 256 indeed sabse chhota adequate power of two hai. 16-register slack (256 − 240) writes ke bursts ko bhi cushion karta hai. ✓

Recall Self-test — answers cover karo

RAW true dependency hai; renaming isse ___ karna chahiye. ::: preserve karna chahiye (source ko producer ke physical register par point karte rakho) WAR aur WAW false hain; renaming inhe ___ karke hata deti hai. ::: har write ko apna fresh physical register dekar Har instruction par fire hone wale teen arrows, order mein, hain ___. ::: ① read sources, ② allocate + record old in ROB, ③ free old at commit ADD R1,R1,R2 ke liye tumhe ___ karna hai ___ se pehle. ::: purani source mapping padho ; naya destination allocate karo Jab free list khaali ho, ___ succeed karta hai lekin ___ stall karta hai. ::: sources padhna (arrow ①) ; allocation (arrow ②) → register pressure Misprediction par tum RAT ___ se restore karte ho; exception par tum ___ unwind karte ho. ::: branch checkpoint ; ROB using recorded old mappings Commit par tum ___ physical register free karte ho, naya wala nahi. ::: old

Yeh kahan connect karta hai

Renaming tables directly Out-of-Order Execution aur Tomasulo's Algorithm mein feed hoti hain, jahan physical tags wahi hain jinka reservation stations wait karti hain.
Reorder Buffer (ROB) woh old-mapping field supply karta hai jis par upar ke har rollback ka daromadar tha.
False hazards hatana exactly woh hai jisse renaming Superscalar Execution mein Instruction-Level Parallelism (ILP) boost karta hai.
Branch Prediction woh checkpoints supply karta hai jo Example 5 mein use hue; simpler Scoreboarding se compare karo jo false hazards rename karne ki jagah unpar stall karta hai.
🇮🇳 Yeh sab Hinglish mein →