Yeh ek self-test page hai. Har line ek Question ::: Answer reveal hai. Answer ko cover karo, apni reasoning zor se bolo, phir check karo. Agar tum answer ko ek sentence mein justify nahi kar sakte, toh samjho abhi tak samjha nahi — parent note dobara padho.
Is page par har question ek hi cheez pooch raha hai: kya machine ne clean line rakhi? Precision matlab hai program order mein ek single dividing line — iske left mein sab fully committed hai (Condition 1), faulting instruction se rightward sab fully erased hai (Condition 2).
Figure s01 (alt-text): paanch instruction boxes I1…I5 program order mein. I1 aur I2 solid green hain ("done, committed"), ek bold blue vertical "clean line" I3 se theek pehle hai, aur I3–I5 dashed red boxes hain ("no-op, erased"). I3 faulting instruction hai.
Recall Prerequisite mechanisms ka 15-second summary (taaki page chhodna na pade)
Reorder Buffer (6.3.4-Reorder-buffer-in-superscalar): ek FIFO queue; instructions program order mein enter karte hain, out of order finish karte hain apne ROB slot mein results likhke, aur ROB head par order mein commit karte hain — commit woh moment hai jab result finally real register file mein jaata hai. Branch prediction (5.2.11-Branch-prediction): pipeline ek branch outcome guess karke speculatively fetch karti hai; wrong guesses flush ho jaate hain, apne saath koi bhi speculative faults le jaate hain.
Jab ek hi instruction kaafi saare faults raise kar sakti hai, toh uske lifetime mein sabse pehle aane wala fault jeetta hai. Yeh ordering pipeline stages ko left-to-right follow karti hai — har stage jo fault raise kar sakti hai woh dikhni chahiye, including MEM stage jahan loads aur stores page-fault, data-TLB miss, ya memory protection violate kar sakte hain:
Figure s02 (alt-text): char boxes ek left-to-right row mein IF, ID, EX, MEM labelled. Har ek apna fault batata hai (IF: instruction page fault / instruction-TLB miss; ID: illegal opcode / privilege; EX: overflow / divide-by-zero; MEM: data page fault / data-TLB miss / protection violation). Gray arrows rightward point karte hain instruction ka lifetime dikhate hue; pehle ke stages ka rank zyada hai.
Priority (highest = 1)
Fault type
Stage caught
Yeh rank kyun
1 (highest)
Instruction page fault / instruction-TLB miss
IF
Instruction ki life mein sabse pehle hota hai
2
Illegal opcode, privilege violation
ID
Decode, fetch ke baad aata hai
3
Overflow, divide-by-zero
EX
Execute aur baad mein hai
4 (lowest)
Data page fault / data-TLB miss / memory-protection violation (load ya store par)
MEM
Memory access sabse aakhri stage hai jo fault kar sakti hai
Ek pipeline jo kabhi instructions reorder nahi karti, automatically precise exceptions deti hai.
False — strict in-order pipeline bhi instructions ko alag alag stages par complete (write back) karne deta hai, toh instruction i−1 abhi bhi MEM mein ho sakta hai jab i EX mein fault karta hai; phir bhi tumhe stall-then-flush control chahiye (front freeze karo, purani instructions drain karo, baaki ko NOP karo) taaki in-order completion force ho sake.
Precise exceptions ke liye zaroori hai ki faulting instruction architectural state par koi trace na chhodhe.
True — yahi Condition 2 upar batata hai: faulting instruction aur saare younger instructions ko registers ya memory modify nahi karna chahiye, taaki handler state dekhe jaisi ek sequential machine dekhti agar execution uss se pehle ruk jaati.
Out-of-order execution precise exceptions ko impossible bana deta hai.
False — OoO execution reorder karta hai, lekin Reorder Buffer (ROB) in-order commit restore karta hai, toh architectural state phir bhi program order mein update hoti hai aur exceptions precise rehte hain.
EPC (Exception Program Counter) mein save kiya gaya program counter faulting instruction ke baad wali instruction par point karna chahiye.
False — precise exception ke liye EPC faulting instruction par hi point karta hai, taaki handler (jaise ek page load karne ke baad) exactly usi instruction ko retry kar sake jo fault hui thi.
Agar do instructions ek hi cycle mein fault karein, toh pipeline ko woh report karna chahiye jo time mein sabse pehle detect hua.
False — use report karna chahiye jo program order mein sabse pehle hai, kyunki sequential semantics ground truth hai; time-of-detection toh sirf ek artifact hai ki kis stage ne fault pakda.
Branch misprediction ek spurious exception cause kar sakta hai agar hum careful nahi hain.
True — speculatively fetch ki gayi wrong-path instructions fault kar sakti hain (jaise divide-by-zero), aur agar hum woh exception lete toh hum ek aise instruction ka fault report karte jo kabhi run honi hi nahi thi.
ROB scheme mein, ek instruction jisne execute finish kar liya usne architectural registers already update kar diye hain.
False — complete results ROB entry mein rehte hain, architectural registers mein nahi; woh architectural state mein tabhi jaate hain jab commit hota hai, jo in-order ROB head par hota hai.
Younger instructions ko flush karna precision guarantee karne ke liye kaafi hai.
False — flushing Condition 2 satisfy karta hai, lekin tumhe saath hi saare purani instructions ko commit finish karne bhi dena hoga taaki Condition 1 satisfy ho; precision ko line ke dono hisson ki zaroorat hai.
False — sabse bada use case page faults hain (jo data accesses ke liye MEM mein aur instruction fetches ke liye IF mein strike karte hain), jahan handler page load karta hai aur exactly faulting instruction se resume karna hota hai; TLB misses, illegal opcodes aur privilege violations sab isi machinery par rely karte hain.
Interrupts (external, asynchronous) ko exceptions se kam precision chahiye.
Partly false — dono requirements alag karo. Kab interrupt lena hai yeh flexible hai: hardware use delay kar sakta hai aur kisi bhi convenient instruction boundary se attach kar sakta hai. Lekin jis bhi boundary ko woh chunti hai, wahan state dono precision conditions satisfy karni chahiye (purani instructions sab committed, younger wali sab abhi bhi un-executed), taaki handler cleanly resume kar sake. Timing relaxed hai; state precision nahi.
"I3 EX mein fault karta hai, toh hum immediately har stage ko wahan rok dete hain aur handler mein jump karte hain."
Galat — immediately rokna I1/I2 ko mid-way freeze kar deta hai, Condition 1 violate hoti hai. Tumhe front ko stall karna hoga, purani instructions (I1, I2) ko pehle WB complete karne deni hogi, aur tabhi I3 aur younger ko flush karke NOP karo aur jump karo.
"Jab I3 fault karta hai toh hum I3 ko NOP bana dete hain lekin time bachane ke liye I4 aur I5 normally execute karte rehte hain."
Galat — I4 aur I5 faulting instruction se younger hain aur not executed dikhne chahiye (Condition 2); unhe NOPs mein flush karna zaroori hai, warna woh clean line corrupt kar denge.
"ROB mein, hum exception tabhi lete hain jab execute unit fault detect kare."
Galat — fault sirf ROB entry mein detection par mark hota hai; exception actually tab liya jaata hai jab woh entry ROB head par pahunche (in-order), toh purani instructions pehle commit hoti hain.
"Wrong branch path par ek speculative divide-by-zero ek real exception hai, hum baad mein fix kar lete hain."
Galat — yeh kabhi bhi real exception nahi hai. Jab branch mispredicted resolve hoti hai, woh instruction flush ho jaati hai aur uski fault bilkul gayab ho jaati hai, jaise woh kabhi fetch hi nahi hui thi.
"Ek hi instruction mein faults ke beech hum hamesha arithmetic fault pehle lete hain kyunki woh sabse severe hai."
Galat — priority stage order follow karti hai, severity nahi: instruction-fetch fault (IF) EX arithmetic fault se upar hai, jo baad mein MEM data fault se upar hai; instruction ke lifetime mein sabse pehle aane wala stage jeeta hai.
"Stall-on-exception ka koi performance cost nahi kyunki exceptions rare hain."
Sirf half right — har exception mein cycles lagte hain. Concretely, ek k-stage pipeline mein machine ko purani instructions drain karni hoti hain aur baaki flush karne hote hain, toh roughly k cycles per exception ka loss hota hai (5-stage pipeline ke liye 5, deeper ones ke liye zyada). Agar exceptions frequency f par aati hain (instructions ka fraction), toh average penalty roughly f×k cycles per instruction hoti hai — tabhi tolerable hai jab f bahut tiny ho jaise page misses ke liye, yeh nahi ki cost zero hai.
"Kyunki ROB results hold karta hai, hum separate architectural registers rakh hi nahi sakte."
Galat — tumhe architectural registers committed checkpoint ke roop mein phir bhi chahiye; ROB ek temporary staging area hai, aur commit precisely woh act hai jo ROB results us checkpoint mein copy karta hai.
Hum har instruction ko result compute karte hi instantly kyun nahi likhne dete?
Kyunki writes tab program order se bahar ho jaate hain, toh ek younger instruction purani instruction ke fault karne se pehle state overwrite kar sakti hai — Condition 1 ke clean prefix aur Condition 2 ke clean suffix dono violate hote hain.
ROB in order commit kyun karta hai jab ki usne out of order execute kiya?
In-order commit hi ek aisa tarika hai jo guarantee karta hai ki kisi bhi commit point par architectural state exactly wahi ho jo ek sequential machine mein hoti — fast execution ko ordered commitment se decouple karna hi poora trick hai.
Page fault specifically precise exceptions kyun demand karta hai?
Handler ko missing page load karni hoti hai aur phir exactly usi instruction se resume karna hota hai jo fault hui thi; agar state imprecise hoti, resume karna ya toh kaam skip karta ya committed kaam dobara karta, galat results deta.
Hum exceptions ko timestamp ki jagah sequence number se kyun tag karte hain?
Sequence number program order encode karta hai, jo woh semantics hai jise hume preserve karna hai; detection time sirf yeh batata hai ki kisi pipeline stage ne pehle notice kiya, jo correctness ke liye irrelevant hai.
Flushing sirf in-flight instructions ke control bits clear karta hai (unhe NOPs bana deta hai), toh woh harmlessly drain hote hain bina state likhein — committed data ka koi rollback kabhi required nahi hota kyunki younger kuch bhi commit nahi hua tha.
Speculative execution humein exceptions defer karne par kyun force karta hai?
Kyunki hume abhi pata nahi ki speculatively fetch ki gayi instruction real path par hai ya nahi; branch resolution tak defer karne se wrong-path faults gayab ho jaate hain aur sirf real-path faults commit tak survive karte hain.
Condition 1 saari purani instructions ko complete karna kyun require karta hai, sirf "kaafi" nahi?
Handler aur baad ka koi bhi resumption ek fully sequential prefix assume karta hai; ek bhi un-committed purani instruction pre-fault state ko incomplete aur un-resumable bana deti.
Agar program ki sabse pehli instruction hi fault kare?
Toh koi purani instruction commit karne ke liye nahi hai (Condition 1 trivially satisfied hai); tum faulting instruction aur younger sabko flush karo, EPC ko uss pehli instruction par set karo, aur initial (unmodified) architectural state ke saath handler enter karo.
Agar faulting instruction khud bhi ek branch ho jo mispredicted thi?
Pehle misprediction resolve karo: agar faulting branch khud correct path par hai toh woh phir bhi fault karti hai aur apna exception commit karti hai; wrong-path successors ka flush waise bhi hota hai, aur branch ka apna fault iss baat se judge hota hai ki branch instruction commit hui ya nahi.
Agar ek hi instruction par do exceptions aayein (jaise IF mein ek instruction-TLB miss aur EX mein ek divide-by-zero)?
Within-instruction priority order use karo — IF faults ka rank sabse upar hai, phir ID (illegal/privilege), phir EX (arithmetic), phir MEM (data faults) — aur sabse high-priority wala report karo, kyunki woh uss instruction ke sequential lifetime mein sabse pehle hota.
Agar ek purani instruction fault kare baad mein jab ek younger instruction already out of order apna result compute kar chuki ho?
Koi problem nahi — younger result uske ROB entry mein trapped hai aur kabhi committed nahi hua; jab purani fault ROB head par pahunche toh hum saare younger entries flush karte hain, woh result discard karte hain, toh precision hold karti hai.
Agar exception handler khud exception cause kare (nested fault)?
Wohi precise-exception machinery recursively apply karni hogi; typically EPC/state ek alag jagah ya stack par save hoti hai re-enter karne se pehle, aur ISA (dekho 3.4.7-Exception-handling-in-ISA) define karta hai ki nested faults kaise sequence hote hain taaki har level precise rahe.
Agar ek instruction fault kare jab zero purani instructions in-flight hain lekin kaafi younger already WB mein hain?
Kyunki younger instructions in-order-commit design mein purani instruction se pehle legally WB tak nahi pahunch sakti, yeh state impossible hai; agar yeh appear ho, toh ordering logic toot gayi hai — yahi woh invariant hai jise precise exceptions defend karte hain.
Recall Ek-line summary lock in karne ke liye
Ek precise exception clean line rakhta hai: fault se pehle sab fully committed (Condition 1), fault aur baad mein sab fully erased (Condition 2), EPC fault par point karta hai, aur simultaneous faults mein program order mein sabse purana jeeta hai — per-instruction ties stage order IF > ID > EX > MEM se break hote hain.
Aage kahan jaayein: ROB mechanics 6.3.4-Reorder-buffer-in-superscalar mein review karo aur ISA-level save/restore contract 3.4.7-Exception-handling-in-ISA mein; ya is bank ke ideas Hinglish mein padho.
