Reorder buffer (ROB): Question bank — Hinglish deep dive

5.3.5 · D5 · Hardware › Advanced Microarchitecture › Reorder buffer (ROB)

Yeh ek rapid-fire misconception hunt hai Reorder buffer (ROB) ke liye. Har line ek single reveal hai: prompt padho, answer out loud bolo, phir check karo. Answers sirf "haan/nahi" nahi dete — reasoning dete hain — aur wahi reasoning asli cheez hai.

Prerequisite ideas jo tumhare dimaag mein pehle se honi chahiye: Out-of-order execution ka in-order retirement stage mein jaana, Reservation-stations se flow hote tags, aur poori cheez Precise-exceptions ko serve karti hai.

Pehle ROB ko picture karo

Traps se pehle, mental image ko anchor karo. ROB ek ring of slots hai. Naye instructions tail pe enter karte hain, ghumte hue aage badhte hain, aur head pe retire karte (nikalta hain). Issue aur retire ke beech, har slot ek chhota status carry karta hai.

Definition ROB entry ke chaar possible states

Ek single entry ek tiny state machine hai. Yeh exactly inhi states se guzarti hai, aur kabhi peeche nahi jaati:

Invalid — slot free hai (kisi bhi instruction ko allocate nahi kiya gaya). Tail aur head ke beech ke slots Invalid hote hain.
Issued (jise Pending bhi kehte hain) — ek instruction ne slot own kar liya hai lekin uska result abhi compute nahi hua; value field khaali hai.
Completed — result compute ho gaya hai aur ROB entry mein likh diya gaya hai (register file mein abhi nahi).
Exception — execution ne ek fault raise kiya (jaise divide-by-zero); entry value ki jagah fault carry karti hai.

Is poore page mein, "Pending" Issued ka shorthand hai, aur Completed aur Exception dono entries ko finished executing kaha jaata hai — lekin kisi ne bhi abhi architectural state ko touch nahi kiya hai.

ROB kitni tezi se retire karta hai usse kya limit karta hai? (IPC bound)

Performance formula mein teen symbols hain. Combine karne se pehle inhe earn karte hain.

Ab bound:

$IPC \leq min (ILP_{available}, \frac{N}{L})$

Sach ya jhooth — justify karo

ROB instructions ko us order mein retire karta hai jis order mein unka execution finish hua.

Jhooth. Yeh strictly program order mein head se retire karta hai; jaldi finish hone se sirf entry Completed state mein wait karti hai — koi younger instruction kabhi kisi older instruction se pehle commit nahi kar sakti.

Ek instruction apna reservation station aur ROB entry ek hi moment mein chodti hai.

Jhooth. Yeh reservation station usi cycle mein free karti hai jab execute karna shuru karta hai (scheduling ho gayi), lekin ROB entry tab tak rakhti hai jab tak woh head nahi ban jaati aur retire nahi ho jaati — aksar kai cycles baad.

Ek completed instruction apna result pehle se architectural register file mein likh chuki hai.

Jhooth. Completed ka matlab hai value apni ROB entry mein baithti hai. Architectural register file mein write sirf retire pe hoti hai, jab woh head pe pahunchti hai.

Agar head == tail hai, toh ROB full hai.

Jhooth. head == tail empty condition hai. Fullness (tail + 1) mod N == head hai, jo jaanboojhkar ek slot waste karta hai taaki dono states distinguish ho sakein.

ROB akela enforce kar sakta hai ki ek hi address pe do loads aur ek store ordered rahein.

Jhooth. ROB store ke architectural effect ki retirement order karta hai, lekin load/store value dependencies ke liye alag load-store queue chahiye; Memory-ordering dekho.

Jhooth. ROB-based scheme mein ROB entry number hi tag hai — newest matching ROB entry ek register ko rename karti hai, jo exactly Register-renaming hai jo buffer ke andar ho raha hai.

Branch misprediction pe flushing branch se purani instructions ko throw away kar deti hai.

Jhooth. Sirf branch ke baad wali entries (wrong-path speculative instructions) flush hoti hain; branch aur usse pehle sab real hain aur rehte hain. Branch-prediction dekho.

Precise exception ka matlab hai faulting instruction ka result discard ho jaata hai lekin uske baad wali commit ho jaati hain.

Jhooth. Precise ka matlab hai fault se pehle ki saari instructions committed hain aur faulting wali aur uske baad ki sab discard hoti hain — machine aisa laagta hai jaise exactly fault pe ruk gayi.

ROB size double karne se IPC hamesha double ho jaata hai.

Jhooth. IPC

min (ILP_{available}, N / L)

se capped hai. Jab ROB size bottleneck nahi raha (program ki parallelism ya dependency-chain latency

L

se limited hai), bada

N

kuch nahi karta.

Kisi instruction ko, chahe uska koi destination register na ho (jaise store ya branch), phir bhi ROB entry chahiye.

Sach. Retirement ke liye program order preserve karne ke liye, exception status ke liye, aur PC ke liye ek entry chahiye — chahe woh koi register value nahi likhti.

Error dhundho

"Jab I3, I1 se pehle complete ho jaata hai, hum time bachane ke liye turant I3 ka result register file mein likh dete hain."

Galat: yeh in-order state ko tod deta hai. Agar ek purani instruction (I1) baad mein fault karti hai, file mein pehle se I3 ki value hogi — ek instruction ki jo "kabhi honi hi nahi chahiye thi." Results retire hone tak ROB mein wait karte hain.

"Source operand dhundhne ke liye, ROB ko head se tail tak scan karo aur pehla match lo."

Galat direction. Tum us register ka newest writer chahte ho, isliye tail se backward scan karo — sabse recent matching entry sahi producer hai.

"Mispredicted branch pe hum poora ROB flush kar dete hain aur fetch restart karte hain."

Galat: tum valid purane kaam ko bhi maaro ge. Sirf un entries ko flush karo jo branch se younger hain; branch aur usse pehle sab correct-path instructions hain.

"Kyunki ROB ek FIFO hai, hum jahan bhi free slot ho wahan naya entry allocate kar sakte hain."

Galat: allocation program order mein tail pe honi chahiye. Arbitrary allocation us ordering ko destroy kar deti hai jo in-order retirement (aur precise exceptions) ko possible banati hai.

"Empty aur full dono conditions head == tail hain, toh hum phas gaye — design broken hai."

Galat: do working designs hain, koi ek chuno. Design A (sacrificial slot):

N - 1

usable entries rakho taaki full (tail+1) mod N == head ban jaaye — simple comparison, lekin ek slot waste hota hai. Design B (occupancy counter): valid entries ka count rakho; full hai count == N, empty hai count == 0 — saare

N

slots use hote hain lekin har cycle mein ek extra increment/decrement chahiye. Dono standard hain; trade-off hai ek wasted slot versus ek extra counter.

"Jo instruction exception raise karti hai woh execution ke dauran detect hote hi flush ho jaati hai."

Galat: entry Exception state mein jaati hai aur fault tabhi act hota hai jab woh head ban jaati hai. Jaldi act karna wrong-path instruction pe flush kar sakta hai jo kabhi retire hi nahi honi chahiye thi.

"ROB woh actual operand values store karta hai jo instruction execute hone ke liye chahiye."

Galat: operand waiting reservation station ka kaam hai. ROB har instruction ka produced result store karta hai (jab Completed ho) plus bookkeeping — woh inputs nahi jinka woh wait kar rahi hai.

Why questions

Execution out-of-order ho, phir bhi retirement in-order kyun honi chahiye?

Kyunki architectural state (registers, memory) ek sequential program run se match karni chahiye taaki exceptions aur interrupts precise ho sakein; sirf in-order commit guarantee karta hai ki purani effects naye se pehle land hon.

ROB entry number ko operand tag ki jagah register name ki jagah kyun use kiya jaata hai?

Kai in-flight instructions same register name ko target kar sakti hain, isliye naam ambiguous hai. ROB index har in-flight instruction ke liye unique hai, jo ek consumer ko exactly ek producer ka wait karne deta hai — yahi Tomasulo-style renaming ko kaam karwata hai.

Ek store aksar apni execution latency se kaafi zyada der tak ROB entry mein kyun rehta hai?

Kyunki use architecturally visible hone ke liye head banana padta hai pehle memory write karane se; execution (address/data ready) jaldi finish ho sakta hai, lekin commit program order se gated hai.

Speculative-execution ko safe rehne ke liye ROB kyun chahiye?

Speculative results sirf ROB staging entries mein rehte hain, architectural state mein kabhi nahi. Agar speculation galat tha, toh un entries ko flush karna kaam ko zero visible side effects ke saath mita deta hai.

Fixed ROB size

N

ke liye zyada lambi dependency-chain latency

L

achievable IPC kyun kam karti hai?

Lambi chain mein instructions apne producers ka wait karte hue apni ROB entries zyada der tak occupy karti hain, isliye fewer distinct instructions har cycle mein in flight ho sakti hain; throughput ceiling

N / L

jaise

L

badhta hai waise gir jaata hai.

Ek superscalar machine ek hi cycle mein kai instructions retire kyun kar sakti hai?

Kyunki agar head aur uske baad ki kuch entries saari Completed hain aur in order hain, toh unhe saath commit karne mein koi ordering violation nahi hai — retirement width ek hardware choice hai, correctness limit nahi.

Edge cases

Kya hoga agar head pe instruction abhi bhi Issued (Pending) hai jabki har younger entry Completed hai?

Kuch retire nahi hoga. Retirement head-gated hai, isliye poora ROB usi ek entry pe stall ho jaata hai — yahi exactly woh case hai jahan ek slow load kai finished instructions ke commit ko block kar sakta hai.

Agar exception-marked entry abhi head nahi ban payi hai toh kya?

Woh Exception state mein wait karti hai. Fault tabhi trigger hota hai jab woh head ban jaati hai — usse pehle program order mein retire ho chuki younger instructions sahi retire ho gayi hain.

Agar branch mispredicted hai lekin branch entry khud abhi head nahi ban payi hai toh kya?

Recovery (younger entries ka flush + fetch redirect) branch resolve hote hi ho sakti hai, retirement ka wait kiye bina, kyunki sirf wrong-path entries remove hoti hain aur branch rehta hai; uska apna architectural effect head pe commit hoga.

ROB exactly usi instant kaisa dikhta hai jab woh empty ho jaata hai?

head == tail aur har entry Invalid hai — wrap-around pointers coincide karte hain. Agli issued instruction tail pe jaati hai aur dono pointers phir se diverge karne lagte hain.

Kya ek hi architectural register mein likhne wali do instructions dono ek saath ROB mein reh sakti hain?

Haan — renaming ka poora yahi point hai. Dono distinct entries ke roop mein coexist karte hain; consumer newest wala padta hai, aur retirement pe purani wali ki write simply overwrite ho jaati hai (ya uski file write harmless hoti hai) program-order semantics preserve karte hue.

Retirement pe kya hoga agar destination register ki value file mein pehle se maujood value ke barabar hai?

Write phir bhi hoti hai (ya ek harmless no-op hai); correctness value ke different hone pe depend nahi karti — yeh depend karti hai ki write program order mein head pe ho.

Recall Ek-line self-test

Sab cover karo aur jawab do: head pointer kaunsi teen cheezein gate karta hai? Answer ::: (1) architectural register file mein in-order write, (2) precise exception ka trigger hona, aur (3) entry ka free hona taaki tail us mein wrap kar sake.