Noesis
5.3.4 · D5 · HinglishAdvanced Microarchitecture

Question bank — Register renaming

2,423 words11 min read↑ Read in English

5.3.4 · D5 · Hardware › Advanced Microarchitecture › Register renaming

Yeh page ek misconception hunter hai. Neeche har item ek aisi jagah ko target karta hai jahan students sochte hain ki unhe Register renaming samajh aa gaya, lekin unke dimag mein ek subtly galat picture hoti hai. Prompt padho, apna jawab ek reason ke saath zor se bolo, phir reveal karo. Agar tumhara justification diye gaye se alag hai — chahe tumhara yes/no match kare — toh tumne ek aisa gap dhundha jo close karne layak hai.

Shuru karne se pehle, chaar words jinpar hum lagaataar rely karte hain, plain English mein restated taaki koi assumption na ho:

  • Architectural register — ek naam jo programmer/compiler likhta hai (jaise R1). Yeh ek label hai, storage box nahi.
  • Physical register — hardware mein ek actual storage box (jaise P0). Yahan number sach mein rehta hai.
  • RAT (Register Alias Table) — ek chhoti si lookup table jo kehti hai "abhi, label R1 ka matlab box P2 hai." Renaming kuch nahi hai sirf is table ko edit karna jab instructions decode hoti hain.
  • ROB (Reorder Buffer) — ek queue jo har us instruction ko yaad rakhti hai jo abhi "in flight" hai (decoded lekin abhi finalize nahi hui), program order mein. Yeh har instruction ki purani register mapping store karta hai taaki mistakes undo kar sake aur results sahi order mein finalize ("commit") kar sake. Poori detail Reorder Buffer (ROB) mein hai.

Teen bookkeepers ki ek picture

Is page ki har cheez teen chhoti structures tak aati hai jo physical boxes ek doosre ko pass karti hain. Neeche ki figure unki jobs aur ek box ke unke beech move karne ka tarika dikhati hai — jawab dene se pehle ek nazar daalo, aur jab bhi koi item RAT, free list, ya ROB ka zikr kare, iske paas wapas aao.

Ownership ke arrows notice karo: ek box free list chhhod deta hai jab destination allocate hota hai (orange), RAT uski taraf point karta hai jab tak yeh ek label ki current value hai (blue), ROB pichle box ko commit tak hold karta hai, aur commit par purana box wapas free list mein push hota hai (green). Har physical box hamesha in homes mein se exactly ek mein hota hai.

R1 → P0 → P2 ki kahani, step by step

Parent note baar baar ek hi example ki taraf wapas jaata hai: teen instructions jo sab R1 likhti hain. Dekho ki label R1 kis box ki taraf point karta hai jab hum unhe decode karte hain — yeh ek figure neeche ke aadhe reveals ke peeche ki intuition hai.

Conclusion: R1 the label ek cheez hai, lekin teen instructions ke baad iska matlab teen alag physical boxes hai (P10 → P0 → P2). Jo reader purana R1 chahta tha (the MUL) wo P0 padhta rehta hai; baad ka writer P2 mein likhta hai. Alag boxes, zero conflict — yahi poora trick hai.

Har cheez kab hoti hai

Kai "ordering trap" items depend karte hain kab ek instruction ki life mein source-read, rename, execute, aur commit hoti hai. Neeche ki timeline us order ko ek baar fix karti hai taaki tum traps ke baare mein reason kar sako.

Ise left se right padho: sources RAT se padhe jaate hain aur destination rename hoti hai decode par (program order mein), execution out of order aur kaafi baad ho sakti hai, lekin purane box ki free hone ki baari commit tak (wapas program order mein) wait karti hai. Har edge case ke liye yeh strip yaad rakho.

True ya false — justify karo

Register renaming RAW (true) dependencies bhi hata deta hai.
False. Renaming sirf false wali (WAR aur WAW) ko khatam karta hai har writer ko uska apna box dekar; RAW ek genuine data need hai, isliye consumer ko producer ki value ka abhi bhi wait karna padega.
Agar do instructions ek hi architectural register mein likhti hain, toh ek write wasteful kaam hai jise hardware skip kar sakta hai.
False. Dono writes execute hoti hain (un par intermediate readers ho sakte hain jinhe values chahiye); renaming bas unhe alag physical boxes mein route karta hai taaki wo ek doosre ko block na karein.
Renaming ke baad, MUL R4,R1,R5 aur ADD R1,R6,R7 ke beech R1 par WAR hazard physically abhi bhi exist karta hai, hum sirf ise hide karte hain.
False. Yeh genuinely exist karna band ho jaata hai: MUL box P0 padhta hai aur ADD ek brand-new box P2 mein likhta hai (figure s02 dekho). Do alag boxes conflict nahi kar sakte — hide karne ke liye kuch bacha hi nahi.
RAT registers ki values store karta hai.
False. RAT mappings store karta hai (label → box number), data nahi. Values khud physical register file mein rehti hain; RAT bas usme ek index hai.
Ek physical register us instruction ke execute hote hi free kiya ja sakta hai jo usme likhti hai.
False. Yeh tab free hota hai jab same architectural register ka next writer commit karta hai — tab tak, ek exception hume purana mapping restore karne par majboor kar sakta hai, isliye purana box survive karna chahiye (timeline s03).
Renaming useful hone ke liye out-of-order execution zaroori hai.
Spirit mein mostly true: renaming exist karta hai Out-of-Order Execution ko zyada independent kaam dene ke liye. Ek strictly in-order pipeline mein false dependencies waise bhi rarely stall karti hain, isliye renaming thoda faida deta hai.
Kafi saare architectural registers ke saath, ek smart compiler renaming ko unnecessary bana deta hai.
False. Compiler statically allocate karta hai aur runtime ordering, loop unrolling depth, ya interrupts pehle nahi dekh sakta; zyada architectural registers binary compatibility bhi tod dete hain aur encoding bloat karte hain. Hardware renaming ise transparently solve karta hai.
Har physical register, kisi bhi instant par, exactly ek mein hota hai: free list, RAT dwara mapped, ya ROB mein purani mapping ke roop mein hold kiya gaya.
True. Free list available boxes hold karta hai; RAT har label ke current box ki taraf point karta hai; ROB superseded boxes hold karta hai jo commit par free hone ka wait kar rahe hain. Koi fourth home nahi hai — yeh exactly figure s01 mein teen-home picture hai.
Renaming program jo results compute karta hai unhe badal deta hai.
False. Yeh sirf kahan intermediate values store hoti hain aur kab instructions run ho sakti hain — yeh badalta hai. Committed architectural state — wo numbers jo program dekhta hai — ek serial run ke identical hai.

Error dhundho

"Hum sources ki current values dhundhne ke liye free list se sources padhte hain."
Error: sources RAT se padhe jaate hain, free list se nahi. RAT tumhe batata hai ki currently kaunsa box har source ko hold karta hai; free list sirf destination ke liye ek fresh empty box supply karta hai (figure s01).
"Commit par hum naye physical register ko free list mein push karte hain."
Error: hum purana box push karte hain (woh jo is architectural register se pehle map hota tha). Naya box abhi-committed value hold karta hai aur tab tak live rehta hai jab tak koi future writer ise supersede nahi karta.
"Kyunki P0 aur P2 alag boxes hain, I2 (jo P0 padhta hai) aur I3 (jo P2 mein likhta hai) ka RAW dependency hai."
Error: unke beech koi dependency nahi hai bilkul bhi. Alag boxes, alag roles — yahi independence wo WAR hazard hai jise renaming ne hataya (figure s02).
"Hum destination box ko sources padhne se pehle allocate karte hain, taaki destination fresh ho."
Error/ordering trap: pehle RAT se sources padho, phir allocate + RAT update karo (s03 mein decode step dekho). Agar ek source hi destination hai (R1 = R1 + R2), toh update ke baad padhna galat box pakad lega.
"Physical register count ka minimum bas ROB size hai."
Error: minimum hai. Tumhe committed state ke liye har architectural register ke liye ek box chahiye plus har in-flight instruction ke liye ek jo destination claim kar chuki hai.
"Register pressure ka matlab hai physical register file physically overheat ho rahi hai."
Error: register pressure ek scheduling stall hai — decode ruk jaata hai kyunki free list khaali hai (saare boxes use mein hain), temperature se koi lena dena nahi.
"Renaming hazards eliminate karta hai, isliye Reorder Buffer (ROB) precise exceptions ke liye ab zaroori nahi."
Error: ROB abhi bhi essential hai. Yeh recovery ke liye purani mappings record karta hai aur in-order commit enforce karta hai taaki exceptions precise lagein — renaming ROB ko feed karta hai, replace nahi karta.

Why questions

Hum ROB mein purani mapping kyun record karte hain instead of sirf RAT ko overwrite karke bhool jaane ke?
Kyunki ek exception ya branch mispredict hume RAT ko roll back karne ki zaroorat pad sakti hai. Saved purana box hume "R1 ka matlab P0 tha" restore karne aur ab-defunct P2 ko reclaim karne deta hai.
Hum purane physical register ko execute-time par free kyun nahi kar sakte instead of commit-time par?
Instructions out of order execute hoti hain, lekin architectural state precise hona chahiye. Jab tak overwriting instruction commit nahi karti, ek pehle ki exception purani value ko wapas correct architectural state bana sakti hai — isliye hum purana box rakhte hain (timeline s03).
Bina renaming ke WAW execution kyun block karta hai, jabki sirf last write "matter" karti hai?
Bina renaming ke dono writes ek box ko target karti hain, isliye hardware unhe serialize karna padta hai guarantee karne ke liye ki program order mein last write jeetegi. Alag boxes ke saath, ordering sirf commit par enforce hoti hai, unhe parallel compute karne ki freedom milti hai.
Ek single instruction ke liye RAT read aur write dono kyun hota hai?
Read: yeh dhundhne ke liye ki sources currently kahan rehte hain. Write: destination ka naya box publish karne ke liye taaki baad ki instructions us architectural register ko padhte waqt yeh result pick up karein na ki stale wala.
Physical register counts powers of two kyun hote hain (jaise 256)?
Register index har internal tag mein ek binary field hai; power of two saare bit patterns use karta hai aur indexing/decoding hardware ko simple aur dense rakhta hai.
Renaming Superscalar Execution mein specifically kyun help karta hai?
Ek superscalar core ek cycle mein kai instructions decode karta hai aur apni wide back-end fill karne ke liye kai independent ready operations chahiye. False dependencies khatam karna exactly woh extra Instruction-Level Parallelism (ILP) expose karta hai.

Edge cases

Instruction R1 = R1 + R1 — same register dono sources aur destination ke roop mein. Kya hoga?
Dono source reads same current box return karte hain (maano P5), phir ek fresh box P8 allocate hoti hai aur RAT R1→P8 set hota hai. RAT update karne se pehle sources padhna hi yeh sahi rakhta hai.
Jab ek nayi instruction ek destination box chahti hai tab free list khaali hai.
Decode stall ho jaata hai (register pressure). Bina free box ke koi mapping nahi ban sakti, isliye front end wait karta hai jab tak ek committing instruction list mein ek wapas na de.
Ek register likhaa jaata hai lekin program khatam hone se pehle dobara nahi padha jaata.
Isko phir bhi ek physical box milta hai aur normally rename hota hai; uska box bas tab free hota hai jab us architectural register ka baad ka writer commit karta hai (ya pipeline drain par reclaim hota hai). Renaming "unused" results detect nahi karta.
Ek instruction rename hoti hai lekin phir ek branch mispredict commit se pehle use khatam kar deta hai.
Recovery par RAT ko wrong-path instructions se pehle ki state mein roll back kiya jaata hai, aur unke allocated boxes free list mein wapas kar diye jaate hain — jaise unhone kabhi kuch claim hi nahi kiya. Branch Prediction dekho.
Ek hi memory address par load aur store — kya renaming unki ordering resolve karta hai?
Nahi. Renaming sirf register names track karta hai. Memory ordering ek alag problem hai jo Memory Disambiguation dwara handle ki jaati hai; renaming is baat ke liye andha hai ki load/store kaunse addresses touch karte hain.
Do independent instructions dono alag architectural registers mein likhti hain — kya koi renaming interaction zaroori hai?
Koi nahi. Dono free list se alag boxes pull karte hain aur alag RAT entries update karte hain; kabhi koi false dependency thi hi nahi hatane ke liye, isliye renaming har ek ke liye independently aage badhti hai.
Ek instruction ek architectural register padhti hai jise kisi bhi earlier in-flight instruction ne nahi likha.
RAT phir bhi ek valid box return karta hai — woh jo us register ki last committed value hold karta hai. Har architectural register hamesha kisi na kisi live box se map hota hai, isliye ek read kabhi undefined nahi hoti.
Recall Fast self-test

Is page par sabse zyada miss ki gayi idea ::: ==Purane boxes commit par free hote hain, execute par nahi==, kyunki precise exceptions ko abhi bhi purani value ki zaroorat pad sakti hai (timeline s03). Doosri sabse zyada miss ki gayi idea ::: Sources RAT se padhe jaate hain aur destinations free list se pull ki jaati hain — do alag structures do alag jobs ke saath (figure s01).

Related deep material: Tomasulo's Algorithm (reservation stations ke through renaming), Scoreboarding (ek purani scheme jo false hazards par stall karti hai instead of unhe rename karne ke), aur parent Register renaming.