Precise exceptions in pipelines — Hinglish notes

5.2.12 · Hardware › Processor Datapath & Pipelining

Intuition Core Problem

Socho 5 instructions ek 5-stage pipeline mein flow kar rahi hain. Instruction 3 EX stage mein ek divide-by-zero exception trigger karta hai. Lekin instruction 4 aur 5 already IF aur ID stages mein hain, aur instruction 2 abhi MEM complete kar chuka hai. Agar hum abhi immediately halt kar dein, toh instructions 4 aur 5 partially execute ho chuki hain, aur instruction 2 complete ho chuka hai—processor state ab sequential execution ke saath inconsistent hai!

Ek precise exception guarantee karta hai: faulting instruction se pehle wali saari instructions fully complete ho jaati hain, faulting instruction aur uske baad wali saari instructions appear karti hain jaise unhone bilkul execute hi nahi kiya. Isse OS handler ek clean, sequential-looking machine state dekh sakta hai, exception handle kar sakta hai, aur potentially cleanly resume ya terminate kar sakta hai.

Precise Exception Kya Hai?

Hum kyun parwah karte hain?

OS exception handlers ko problem fix karne ke liye predictable state chahiye hoti hai (page fault → disk se page load karo, phir retry karo).
Debuggers ko accurate state dikhani hoti hai jab koi breakpoint ya fault ho.
Correctness: Precise exceptions ke bina, exception ke baad resume karne par galat results aa sakte hain (kuch instructions half-done, kuch skip ho gayi).

Pipelining Precision Ko Kaise Todta Hai

Ek classic 5-stage pipeline (IF, ID, EX, MEM, WB) mein:

Problem 1: Out-of-order completion

Instruction $i$ EX mein fault kar sakta hai, lekin instruction $i - 1$ abhi bhi MEM/WB mein hai aur usne write back nahi kiya.
Instruction $i + 1, i + 2$ already fetch/decode ho chuki hain.

Problem 2: Multiple exceptions

Instruction $i$ ek TLB miss trigger karta hai (MEM stage mein).
Instruction $i + 1$ ek illegal opcode trigger karta hai (ID stage mein).
Hum kaunsa report karein? Sequential execution mein $i$ pehle aata, lekin pipeline ne $i + 1$ ki fault time mein pehle detect ki!

Problem 3: Branch mispredictions

Humne speculatively branch ke baad instructions fetch kar li hain. Agar branch mispredicted tha aur un speculative instructions mein se koi fault karti hai, toh hum woh exception nahi leni chahiye—woh instructions kabhi execute honi hi nahi chahiye thi!

Precise Exceptions Achieve Karne Ke Mechanisms

1. In-Order Completion with Pipeline Stall

Yeh step kyun? Stalling ensure karta hai ki koi nayi instruction pipeline mein nahi aati jab hum pehle waliyon ke finish hone ka wait kar rahe hain. Flushing speculative ya faulted instructions ko remove karta hai taaki woh state modify na karein.

Worked example Stall-on-Exception Walkthrough

Pipeline snapshot jab DIV instruction 3 fault karti hai (EX mein divide-by-zero):

Cycle 5:
IF: I5 (ADD)
ID: I4 (SUB)
EX: I3 (DIV) ← FAULT DETECTED
MEM: I2 (LOAD)
WB: I1 (AND)

Actions:

IF aur ID stages stall karo (PC freeze karo, nayi instructions decode mat karo).
I3, I4, I5 ko NOPs (bubbles) mein convert karo taaki woh registers mein write na karein.
I2 ko WB tak proceed karne do (cycle 6), phir I1 ka WB finish hone do.
I2 ka WB complete hone ke baad, I3 se pehle ki saari instructions done hain.
I3 ka PC EPC mein save karo, I3-I5 flush karo, handler par jump karo.

State ab: I1 aur I2 complete, I3-I5 ne kabhi registers/memory modify nahi kiya → precise!

2. Reorder Buffer (ROB) – Out-of-Order Execution with In-Order Commit

Modern processors performance ke liye out-of-order (OoO) execution use karte hain lekin phir bhi precise exceptions chahiye hoti hain. Reorder Buffer isko solve karta hai.

Formula Reorder Buffer Mechanism

Instructions ko order mein ROB mein issue karo, har ek ko ek ROB entry (sequence number) assign karo.
Out-of-order execute karo: Instructions jab unke operands ready hoon tab complete hoti hain, results ROB mein likhti hain (abhi architectural registers mein nahi).
In order commit karo: ROB head pointer tabhi aage badhta hai jab oldest instruction bina exception ke complete ho jaaye. Commit par, ROB se results architectural registers/memory mein copy karo.
Exception par: Faulting ROB entry mark karo. Jab woh ROB head tak pahunche, saare younger entries flush karo, saare older entries commit karo, phir exception lo.

Yeh kyun kaam karta hai: Architectural state updates sirf commit par hoti hain (program order mein), isliye exceptions automatically precise hoti hain.

Worked example ROB with Exception

Instructions:

I1: ADD R1, R2, R3
I2: LOAD R4, 0(R5)
I3: DIV R6, R7, R0  ← divide by zero
I4: SUB R8, R9, R10

Execution:

I1, I2, I4 execute karte hain aur jaldi finish karte hain (out-of-order).
I3 execute unit mein exception detect karta hai, ROB entry 3 ko "FAULTED" mark karta hai. ROB state:

Entry | Inst | Status       | Result
------|------|--------------|--------
1     | I1   | COMPLETE     | R1=...
2     | I2   | COMPLETE     | R4=...
3     | I3   | FAULTED      | (exception: div-by-zero)
4     | I4   | COMPLETE     | R8=...

Commit process:

I1 commit karo (ROB head) → architectural R1 update karo.
I2 commit karo → architectural R4 update karo.
ROB head I3 tak pahunchta hai → exception commit point par detect hoti hai.
ROB se I3 aur I4 flush karo (architectural R6, R8 kabhi update nahi hue).
I3 ka PC EPC mein save karo, handler par jump karo.

Result: I1, I2 complete, I3 aur I4 ne state modify nahi ki → precise exception.

Yeh step kyun? ROB execution (fast, out-of-order) ko commitment (slow, in-order) se decouple karta hai. Architectural state ek "checkpoint" hai jo tabhi aage badhta hai jab hum sure hoon ki earlier instructions fault nahi kar rahi.

3. Speculative Execution aur Branch Mispredictions

Pipelines speculatively fetch karti hain branches ke baad instructions, yeh jaane bina ki branch liya jayega ya nahi. Agar hum mispredict karein:

Worked example Speculative Fault Example

Code:

BEQ R1, R2, TARGET    ; I1: branch
DIV R3, R4, R0        ; I2: divide by zero (fall-through path par)
TARGET: ADD R5, R6, R7; I3: (branch target)

Scenario: Pipeline predict karti hai branch not taken, I2 fetch karta hai. I2 EX stage mein fault karta hai. Kya hota hai:

I2 ko ROB mein "faulted, speculative" mark karo.
Branch resolve hota hai: branch actually taken tha → I2 galat path par hai.
ROB se I2 flush karo (exception discard ho jaati hai).
I3 fetch karo (correct path), execution continue karo.

Yeh step kyun? I2 mein fault irrelevant hai kyunki I2 ko kabhi execute hi nahi hona chahiye tha. Precision ka matlab hai sirf actual execution path par faults report kiye jaate hain.

Multiple Simultaneous Exceptions

Agar pipeline mein multiple instructions same cycle mein exceptions detect karein, toh hum program order mein earliest wali report karni chahiye (precise exceptions ko sequential semantics chahiye hoti hain).

Worked example Multiple Exceptions

Pipeline snapshot:

IF: I5 (normal)
ID: I4 (illegal opcode) ← EXCEPTION A
EX: I3 (divide by zero) ← EXCEPTION B
MEM: I2 (normal)
WB: I1 (normal)

Decision: I3 program order mein I4 se older hai. I3 ki exception report karo (divide-by-zero), I4 aur I5 flush karo.

Kyun? Sequential execution I3 par pehle fault karta; I4 kabhi reach hi nahi hota.

Common Mistakes

Active Recall Practice

Recall Feynman Explanation (Ek 12-saal ke bacche ko explain karo)

Socho tum ek factory assembly line mein toy cars bana rahe ho. Paanch stations hain: parts uthao, wheels assemble karo, body paint karo, decals lagao, box mein dalo.

Ab, station 3 (paint) par, ek worker ek toy mein cracked body dhoondh leta hai—woh defective hai. Lekin toys already stations 4 aur 5 par ja chuki hain, aur station 2 apni car finish karke station 3 mein bhej chuka hai. Agar tum line abhi rok do, tumhare paas hai:

Toys stations 4 aur 5 mein (jinpar kaam nahi hona chahiye tha kyunki cracked wali sab kuch rokna chahiye thi).
Cracked toy kahin beech mein hai. Precise exception kuch aise kehne jaisa hai: "Theek hai, cracked wali se pehle wali saari toys line finish karke box ho jaayein. Cracked toy aur uske baad wali saari toys ko finish kiye bina throw away karo. Ab factory aisa lagti hai jaise exactly cracked toy par ruki—clean!"

Is tarah, agar manager (operating system) aaye, toh woh ek clean state dekhe: kuch finished toys, defect point par ek kharaab toy, aur uske baad kuch bhi mess nahi hua.

Connections

5.2.1-Pipelining-basics – Precise exceptions pipeline control mein overhead add karte hain.
5.2.8-Data-hazards-and-forwarding – Hazards exception handling ke saath interact karte hain (ek forwarded value faulting instruction se ho sakti hai).
5.2.11-Branch-prediction – Speculative execution ke liye careful exception management chahiye.
6.3.4-Reorder-buffer-in-superscalar – ROB modern OoO processors mein primary mechanism hai.
7.2.5-Virtual-memory-exceptions – Page faults common precise exceptions hain.
3.4.7-Exception-handling-in-ISA – ISA exception types aur handler entry points define karta hai.

#flashcards/hardware

Precise exception kya hota hai? :: Ek aisa exception jahan faulting instruction se pehle wali saari instructions complete ho chuki hain, faulting instruction aur uske baad wali saari instructions ne architectural state modify nahi ki, aur PC faulting instruction ki taraf point karta hai.

Pipelined processors ko precise exceptions ki zaroorat kyun hai?

Taaki OS exception handler ek clean, sequential-looking machine state dekhe, jo correct recovery, resumption, ya termination allow kare. Debuggers aur correctness bhi isi par depend karte hain.

Pipelining exception precision ke liye do main problems kya create karta hai?

(1) Out-of-order completion (jab baad wali fault kare, earlier instructions done nahi hoti). (2) Multiple exceptions simultaneously detect hoti hain (kaunsi report karein?).

Stall-on-exception strategy kya karta hai?

Pipeline freeze karo, faulting instruction se pehle wali saari instructions WB complete karne do, faulting instruction aur uske baad wali saari flush karo, faulting PC save karo, phir handler par jump karo.

Reorder Buffer (ROB) precise exceptions kaise achieve karta hai?

ROB program order mein (oldest pehle) instructions commit karta hai, chahe woh out-of-order execute hon. Exceptions tabhi li jaati hain jab faulting instruction ROB head tak pahunche, yeh ensure karta hai ki earlier instructions commit ho chuki hain aur baad wali nahi.

Exceptions ke context mein speculative instruction kya hoti hai?

Branch resolve hone se pehle predicted branch ke baad fetch ki gayi instruction. Agar branch mispredict kare, toh instruction galat path par hai aur exception cause nahi karni chahiye.

Agar pipeline mein do instructions same cycle mein exceptions detect karein, toh kaunsi exception report ki jaati hai?

Program order mein older instruction ki exception (earliest sequence number), sequential semantics maintain karne ke liye.

Exception detect hote hi pipeline immediately kyun halt nahi kar sakte?

Kyunki earlier instructions (MEM/WB stages mein) abhi bhi architectural state update karna finish nahi ki hain. Abhi halt karna state inconsistent chhod deta.

Precise exceptions mein EPC register ka kya role hai?

EPC (Exception Program Counter) faulting instruction ka address store karta hai, taaki handler ko exactly pata ho fault kahaan hua aur woh state correctly resume ya inspect kar sake.

ROB instructions execute hote hi commit kyun nahi karta?

Program order aur exception precision maintain karne ke liye. Agar younger instruction kisi older wali se pehle commit kare jo baad mein fault kare, toh younger commit "undo" karna padega (bahut mushkil). In-order commit isse rokta hai.