Out-of-order execution: Question bank — Hinglish deep dive

5.3.2 · D5 · Hardware › Advanced Microarchitecture › Out-of-order execution

Shuru karne se pehle, ensure karo ki ye words solid feel ho rahe hain. Agar koi fuzzy lage, toh sab parent note mein zero se build kiye gaye hain.

True or false — justify

TF1. "Out-of-order execution ek single-threaded program ka computed answer badal sakta hai."

False — true (RAW) data dependencies hamesha respect ki jaati hain, aur results sirf in-order commit par visible hote hain, isliye observable answer in-order execution ke identical hota hai.

TF2. "Agar instructions in order commit hoti hain, toh unhe in order execute bhi hona chahiye."

False — execute aur commit alag phases hain; instructions tab execute hoti hain jab unke operands ready hote hain (out of order), lekin ROB commit step ko wapas program order mein force karta hai.

TF3. "Register renaming ek RAW (read-after-write) dependency ko remove kar sakta hai."

False — renaming sirf false dependencies (WAR/WAW) ko remove karta hai jo register names reuse karne se hoti hain; RAW genuine data-flow hai, isliye reader ko real value ka intezaar karna hi padega. Dekho 5.3.04-Register-renaming.

TF4. "Zyada wide issue width (zyada execution units) hamesha IPC badhata hai."

False — IPC window-limited ILP, execution width, aur critical-path ILP ke minimum se bound hota hai; agar ek lamba dependency chain dominate kare, toh extra ports idle baithe rehte hain.

TF5. "Reorder buffer instructions ko usi order mein store karta hai jismein wo execute hoti hain."

False — ROB ek circular queue hai program order mein; instructions apne result slots out of order fill kar sakti hain, lekin head hamesha oldest un-committed instruction par point karta hai.

TF6. "Ek speculatively executed instruction jo baad mein squash ho jaati hai, wo ek real register modify karti hai."

False — uska result sirf ek physical register / ROB slot mein rehta hai aur flush par discard ho jaata hai; wo kabhi architectural state tak nahi pahunchta, isliye koi real register ya memory nahi badalti.

TF7. "OoOE branch prediction ki zaroorat khatam kar deta hai."

False — CPU ko phir bhi branch ke baad window fill karne ke liye instructions fetch karne ka andaza lagana padta hai; galat guesses ROB flush se clean up hoti hain, lekin 6.2.03-Branch-prediction ke bina window starve ho jaata. Dekho 5.3.03-Speculative-execution.

TF8. "Enough physical registers ke saath, WAW hazards poori tarah khatam ho jaate hain."

True — ek WAW hazard ek naam ki collision hai; har write ko ek fresh physical naam dene se do writes ek hi architectural register par kabhi contend nahi karte, jo exactly renaming karta hai.

TF9. "In-order commit ka matlab hai CPU essentially in-order hai aur kuch gain nahi hota."

False — sirf final visibility step ordered hai; saari latency-hiding out-of-order execute phase mein hoti hai jahan independent work ek slow load ke shadow mein fire hota hai.

Spot the error

SE1. "Maine R1=R2+R3 phir R4=R1*R5 mein R1 rename kiya, toh ab wo dono parallel chal sakte hain."

Galat — doosri instruction wo R1 padhti hai jo pehli likhti hai (ek RAW), jise renaming break nahi kar sakta; sirf ek reused register ke do independent writers parallel ho sakte hain.

SE2. "Common Data Bus har result ko exactly ek waiting reservation station tak bhejta hai."

Galat — CDB broadcast karta hai; har reservation station usse simultaneously snoop karti hai taaki jo bhi instructions same tag ka wait kar rahi hain wo parallel mein wake up ho jayein, sequential wakeup delays se bachte hue.

SE3. "Instruction 5 fault hua, toh CPU 1–4 commit karta hai aur phir 5 ke already-computed result ko bhi commit karta hai handler mein jump karne se pehle."

Galat — ek faulting instruction commit nahi hoti; uska apna result aur uske baad ki sab cheez flush ho jaati hai, architectural state instruction 4 par rehta hai, phir exception handler run hota hai.

SE4. "600-entry instruction window 1-entry window se 600× parallelism deta hai."

Galat — window size sirf bound karti hai ki tum kitna aage dekh sakte ho; actual parallelism true dependency chains (critical path) aur execution ports ki sankhya se cap hoti hai.

SE5. "Kyunki I4 aur I5 ne I3 fault karne se pehle execute kar liya, unke memory par side effects already ho gaye."

Galat — stores ek buffer mein rakhe jaate hain aur sirf commit par release hote hain; kyunki I4/I5 kabhi commit nahi hote, unke memory writes kabhi visible nahi hote, precise exceptions preserve hote hain.

SE6. "Ek reservation station ek instruction ko tab tak hold karti hai jab tak ek execution unit free nahi hoti, isliye operands irrelevant hain."

Galat — ek instruction tabhi ready hoti hai jab dono operands aa jaate hain (Ready(src1) ∧ Ready(src2)); wo uske baad hi ek execution unit ke liye compete karti hai, isliye operand availability primary gate hai.

SE7. "Kyunki OoOE loads aur stores ko reorder karta hai, do threads hamesha automatically consistent memory dekhenge."

Galat — single-thread ordering preserve hoti hai, lekin across cores reordering 5.5.02-Memory-consistency-models aur 5.4.01-Cache-coherence ke saath interact karta hai; dusre threads reordered effects observe kar sakte hain jab tak fences/protocols unhe constrain na karein.

Why questions

WQ1. "Program order mein commit kyun karein jab execution out of order ho?"

Precise, sequential-looking architectural state rakhne ke liye taaki exceptions, interrupts, aur debuggers ek clean point dekh sakein jahan "pehle sab hua, baad mein kuch nahi hua."

WQ2. "Physical registers architectural registers se kaafi zyada kyun hote hain?"

Har in-flight write ko WAR/WAW false dependencies break karne ke liye apna physical naam chahiye; ~200 instructions in-flight ke saath tumhe 16–32 se kaafi zyada physical names chahiye jo ISA expose karta hai.

WQ3. "OoOE naturally superscalar aur speculative execution ke saath kyun pair karta hai?"

5.3.01-Superscalar-architecture multiple ports provide karta hai taaki kai ready instructions per cycle issue ho sakein, aur 5.3.03-Speculative-execution window ko branches ke baad fill rakhta hai — OoOE wo scheduler hai jo 7.1.01-Instruction-level-parallelism maximize karne ke liye dono exploit karta hai.

WQ4. "Hum ek infinitely large instruction window kyun nahi bana sakte aur infinite IPC tak nahi pahunch sakte?"

Kyunki critical dependency path ek hard floor set karti hai: infinite window aur infinite ports ke saath bhi, ek chain A→B→C→D serially execute honi chahiye, isliye IPC data-flow graph ki ILP par saturate hoti hai.

WQ5. "Ek slow LOAD OoOE mein independent arithmetic ko stall kyun nahi karta?"

Independent arithmetic ka load ke result par koi RAW dependency nahi hai, isliye wo load ke multi-cycle shadow mein ek free port par fire hota hai rather than uske peche wait karne ke, jo sirf 5.1.01-Pipelining achieve nahi kar sakta tha.

WQ6. "RAT compile time par fix karne ke bajaye dynamically update kyun honi chahiye?"

Architectural se physical registers ka mapping har baar tab badalta hai jab ek architectural register likha jaata hai; sirf running machine current in-flight state jaanta hai, isliye Register Alias Table rename time par per-instruction update hoti hai.

Edge cases

EC1. "Kya hota hai jab reorder buffer completely full ho jaata hai?"

Front-end ko stall hona padta hai — koi nayi instruction dispatch nahi ho sakti jab tak head commit karke ek slot free na kare, isliye head par ek long-latency load back-pressure kar sakta hai aur fetching rok sakta hai.

EC2. "Kya hota hai agar do ready instructions same execution port same cycle mein chahti hain?"

Wo contend karte hain aur sirf ek issue hoti hai; doosri next cycle ka intezaar karti hai (abhi bhi ready), isliye execution width teen IPC-limiting factors mein se ek hai.

EC3. "Store ka result execution aur commit ke beech mein kahan rehta hai?"

Wo ek store buffer mein baitha rehta hai aur cache/memory mein nahi likha jaata jab tak commit na ho, isliye ek mispredicted ya faulting path apne memory writes kabhi leak nahi karta.

EC4. "Kya hota hai agar ek block ki har instruction previous par depend kare (ek pure chain)?"

OoOE koi speedup nahi deta — critical-path limit dominate karti hai, har instruction apne predecessor ka intezaar karti hai, aur ek bada window aur kaafi ports waste ho jaate hain.

EC5. "Kya hota hai agar ek branch prediction galat nikle baad mein jab dependent work already execute ho chuki ho?"

Saari instructions jo wrong path par fetch hui thi ROB se flush ho jaati hain aur unke physical registers reclaim ho jaate hain; architectural state branch tak roll back ho jaata hai, phir correct-path fetch resume hoti hai.

EC6. "Kya hota hai WAR/WAW hazards ke saath jab machine free physical registers khatam kar leti hai?"

Renaming aage nahi badh sakti, isliye rename/dispatch stage stall ho jaata hai — hazards khud logically removable hain, lekin unhe remove karne ka physical resource exhausted hai.

EC7. "Ek correct single-threaded program ke liye in-order aur out-of-order execution mein observable difference kya hai?"

Final architectural result mein koi nahi — sirf timing (kam stall cycles) alag hoti hai; har commit boundary par registers aur memory mein values identical hoti hain.

Recall Lock karne ke liye ek-line summary

OoOE latency hide karne ke liye execution reorder karta hai lekin observable commit kabhi reorder nahi karta, isliye single-thread results unchanged rehte hain; upar ke har trap mein internal (speculative, out-of-order) state ko visible (committed, in-order) architectural state se confuse kiya gaya hai.