Instruction-level semantics and exceptions: Worked examples

5.1.12 · D3 · Hardware › Instruction Set Architecture (ISA) › Instruction-level semantics and exceptions

Pehle, woh words jo hum poore page mein use karte hain: commit aur retire

Kisi bhi example se pehle, hume ek idea define karna zaroori hai jiska parent note ne sirf ishara kiya tha, kyunki har "which PC?" ka jawab chhupe taur par isi par depend karta hai.

Figure — Instruction-level semantics and exceptions

Do model conventions jo hum pehle se fix karte hain taaki baad mein kuch bhi ambiguous na ho:

Scenario matrix

Yeh us case-classes ka poora grid hai jo yeh topic aap par throw kar sakta hai. Iske baad wali figure wohi grid hai jo ek coloured map ki tarah draw ki gayi hai, taaki aap ek nazar mein dekh sako ki nau cases space of behaviours ko kaise partition karte hain (ek axis par return-PC rule se, doosri par cause se).

#	Case class	Distinguishing question	Covered by
A	Fault on a memory access	Return to same instruction	Ex 1
B	Trap (deliberate)	Return to next instruction	Ex 2
C	Abort (unrecoverable)	Koi return nahi	Ex 3
D	Zero / degenerate input (÷0)	Fault data se trigger hoti hai, address se nahi	Ex 4
E	Tie-break — do faults same cycle mein	Program-order-oldest report karo	Ex 5
F	Asynchronous interrupt	Kisi ek instruction se tied nahi; ise kahan insert karein	Ex 6
G	Speculative / squashed instruction faults	Ek fault jo throw away honi chahiye	Ex 7
H	Word problem (real syscall trace)	Kaafi saare rules ko chain karke joodo	Ex 8
I	Exam twist — branch delay / limiting PC	Kaun sa PC jab faulting instr bhi PC change kare?	Ex 9

Do ideas har cell mein repeat hoti hain, toh inhe abhi pin karo:

Recall Woh ek number jo sab decide karta hai: return PC

Handler Exception PC (EPC) mein kaun sa PC save karta hai? Fault ::: faulting instruction ki address khud (use retry karo) Trap ::: next instruction ki address (hum kaam kar chuke hain) Abort ::: koi return nahi — program kill ho jaata hai Interrupt ::: next instruction ki address jo abhi tak committed nahi hui (jahan pause kiya tha wahan resume karo)

Ek fixed-length ISA assume karo: har instruction 4 bytes ki hai, toh "next instruction" ka matlab hai "current address $+ 4$ " jab tak branch kuch aur na kahe.

Ex 1 — Cell A · Load par Fault

Worked example Fault:

LW R5, 0(R6) address 0x1000 par, page resident nahi R6 mein jo address hai uska page physical memory mein nahi hai, toh hardware page fault raise karta hai.

Forecast: padhne se pehle guess karo — OS page load karne ke baad, execution 0x1000, 0x1004, ya kahin aur resume hogi? Aur kya R5 likha jaayega ya untouched rahega?

Classify karo. Yeh ek fault hai (dekho Virtual Memory and Page Faults): correctable, detect hoti hai before instruction commit kare. Yeh step kyun? Family return PC determine karti hai; baki sab usi se follow hota hai.
State check. Kyunki exception precise honi chahiye, R5 modify nahi hoti — koi half-load nahi. Kyun? Agar R5 partly likhaa hota, toh load ko re-run karna unsafe hota; precision ek clean restart point guarantee karta hai. (LW kabhi committed nahi hua, toh uska koi bhi computed result R5 tak nahi pahuncha.)
Return PC. $E P C = 0 x 1000$ — LW ki address khud. Kyun? OS missing page fix karta hai, phir wahi load dobara run hona chahiye taaki data actually fetch ho sake.

Verify: Handling ke baad, CPU 0x1000 par jump karta hai, LW re-execute karta hai, aur is baar page present hai, toh R5 ko uski value milti hai. Koi instruction skip nahi hui, koi double-run nahi hua. $E P C = 0x1000 = 4096$ .

Neeche wali figure is fault ko ek trap ke saath same picture par place karti hai taaki EPC arithmetic visual ho.

Ex 2 — Cell B · Trap (deliberate)

Worked example Trap:

SYSCALL address 0x2040 par Program deliberately ek OS service request karta hai (dekho System Calls and Privilege Levels).

Forecast: 0x2040 ya 0x2044 par return?

Classify karo. Ek trap — synchronous aur iska "matlab" (request issue karo) complete aur commit ho jaata hai. (Ek breakpoint ya invalid-opcode trap bhi isi tarah classify hoga.) Kyun? Program ne khud maanga tha; hum chaahte hain baad mein continue karein, request repeat na karein.
Return PC. $E P C = 0 x 2040 + 4 = 0 x 2044$ — next instruction. Kyun $+ 4$ ? Syscall ko re-run karne se request do baar issue hogi (jaise bytes do baar likhna).

Verify: $0 x 2040 + 4 = 0 x 2044$ . Ex 1 se contrast karo: same mechanism (handler par jump karo, EPC save karo), opposite EPC choice — sirf isliye kyunki trap ne apna kaam committed kiya aur fault ne nahi.

Ex 3 — Cell C · Abort (koi return nahi)

Worked example Abort:

0x30A0 par ek instruction fetch karte waqt uncorrectable ECC error Memory aisa data return karti hai jo apna error-correcting-code check fail karta hai aur repair nahi ho sakta.

Forecast: hum kaun sa EPC compute karte hain?

Classify karo. Ek abort — unrecoverable hardware failure. Kyun? Kitni bhi "try again" corrupted physical memory ko fix nahi karti.
Return PC. Koi meaningful return PC nahi hai. OS fault log karta hai aur typically process kill karta hai (ya panic karta hai agar kernel state tha). Kyun? Precise-restart semantics assume karta hai ki cause remove ki ja sakti hai. Yahan nahi ho sakti, toh restart definition se impossible hai.

Verify: Matrix aborts ke liye "restartable? = No" predict karta hai — consistent. Ex 1/Ex 2 ke unlike, PC par koi arithmetic bhi required nahi.

Ex 4 — Cell D · Zero / degenerate input (÷0)

Worked example Data-triggered fault:

DIV R7, R8, R9 0x4000 par R9 = 0 ke saath Integer division by zero.

Forecast: kya yeh fault hai ya trap? Kaun sa PC?

Apni convention batao (pehle yeh padho!). ÷0 fault hai ya trap yeh ek ISA design choice hai, koi universal truth nahi. Kaafi real ISAs (jaise x86 #DE) divide-error ko trap treat karte hain aur next PC par return karte hain. Is page ki abstract machine ise FAULT treat karti hai taaki hum ek data-driven condition par "retry after fixing the cause" behaviour illustrate kar sakein. Ise call out kyun kiya? Agar aap yeh skip karo, toh answer ek real x86 manual ke saath contradictory lagta hai.
Classify karo (hamare convention ke under). Ek fault — detect hoti hai before R7 likhaa jaaye, restartable in principle (OS ek signal deliver kar sakta hai aur ek handler ko operand fix karne de sakta hai). Kyun? Division ne koi valid result produce nahi kiya, toh kuch bhi committed nahi hua — R7 untouched hai.
Degenerate-input note. Ex 1 ke unlike, trigger operand value (R9 = 0) hai, koi address nahi. Exception purely data se fire hoti hai. Yeh kyun matter karta hai? Unchanged re-run karne se dobara fault hogi — toh OS ko kuch change karna hoga (R9 fix karo, ya signal handler mein PC advance karo) resume karne se pehle.
Return PC (hamaari convention). $E P C = 0 x 4000$ — DIV khud. Kyun? Fault rule: cause address hone ke baad faulting instruction retry karo. (Ek aise ISA par jo ise trap banata hai, EPC instead $0 x 4000 + 4 = 0 x 4004$ hoga.)

Verify: $R 9 = 0$ makes $R 8/ R 9$ undefined, toh R7 untouched rehta hai — precise. Fault EPC $= 0 x 4000 = 16384$ ; trap-convention alternative $0 x 4004 = 16388$ hoga.

Ex 5 — Cell E · Do faults, same cycle (tie-break)

Worked example Priority:

DIV 0x5010 par (÷0) aur older LW 0x5008 par (page fault), same cycle detect hue Dono exceptions same clock cycle mein ready hain. Program order mein LW (0x5008) older hai DIV (0x5010) se.

Forecast: CPU pehle kaun si exception report karta hai?

Order rule. Program-order-oldest faulting instruction ki exception report karo ⇒ LW at 0x5008. Kyun? Precise semantics kehti hai reported fault se pehle ki har cheez committed honi chahiye. Agar hum pehle DIV report karein, toh hum claim kar rahe honge ki LW committed — lekin nahi hua (yeh fault hua). Sequential world mein impossible.
DIV ka kya hoga? Use squash kiya jaata hai (commit se pehle discard) aur abhi report nahi kiya jaata. OS page fault handle karne aur 0x5008 par restart karne ke baad, execution forward flow karti hai aur ho sakta hai DIV tak dobara pahunche, jo dobara fault karega — aur tab report hoga. Kyun? Ek waqt mein sirf ek clean commit boundary exist karta hai; oldest un-committed fault uska malik hai.

Verify: $0 x 5008 < 0 x 5010$ , toh LW older hai ⇒ reported ⇒ $E P C = 0 x 5008 = 20488$ . DIV ki fault defer hoti hai, Out-of-Order Execution and the Reorder Buffer retire-in-order rule se match karta hai.

Ex 6 — Cell F · Asynchronous interrupt (masking & priority ke saath)

Worked example Interrupt: timer fire karta hai jab CPU

0x6100 aur 0x6104 ke beech mein ho Ek hardware timer (dekho Interrupts and I/O) ek interrupt raise karta hai — current instruction ke data se koi lena dena nahi.

Forecast: kya return PC kisi faulting instruction se tied hai? Hum kahan resume karte hain? Aur agar timer ek page fault ke saath hi fire kare toh?

Classify karo. Ek interrupt — asynchronous. Kisi instruction ki semantics ki wajah se nahi hota. Yeh kyun matter karta hai? Program ko re-run karne se yeh same spot par reproduce nahi hoga (ek exception ke unlike, jo instruction stream ka deterministic function hai).
Masking check. Interrupts ko mask kiya ja sakta hai — temporarily block kiya jaata hai jab CPU kisi critical region mein ho ya already ek higher-priority handler service kar raha ho. Agar timer mask hai, woh simply wait karta hai (pending rehta hai) unmask hone tak; current instruction stream undisturbed rehti hai. Yeh include kyun kiya? Faults aur traps ko mask nahi kiya ja sakta (woh ek instruction ki meaning ka hissa hain); interrupts ko kiya ja sakta hai. Yeh ek real, testable difference hai.
Priority. Agar kaafi saare interrupts pending hain, CPU highest-priority wala pehle leta hai; neeche wale pending rehte hain. Ek timer ek keyboard se aage ho sakta hai, for example.
Insertion point (agar unmasked ho). Hardware ek clean commit boundary choose karta hai: woh 0x6100 wali instruction commit karne deta hai, younger not-yet-committed kaam squash karta hai, aur next uncommitted PC record karta hai.
Return PC. $E P C = 0 x 6104$ — next instruction par resume karo jo abhi committed nahi hui thi. Kyun $+ 4$ ? Hum pause kar rahe hain, retry nahi; 0x6100 wali instruction already committed ho gayi.
Coincidence rule (interrupt + exception same cycle mein). Same boundary par ek synchronous exception asynchronous interrupt se jeet jaata hai: exception instruction stream se belong karti hai aur state precise rakhne ke liye handle honi chahiye; interrupt abhi bhi pending hai aur immediately baad mein liya jaata hai. Kyun? Interrupt ko ek un-handled fault ke "upar" deliver karna imprecise state chhod dega.

Verify: $0 x 6100 + 4 = 0 x 6104$ . Ek trap (Ex 2) jaisi EPC arithmetic, lekin cause external hai, instruction nahi — parent note se "synchronous vs asynchronous" distinction.

Ex 7 — Cell G · Speculative instruction jo fault karti hai, phir squash ho jaati hai

Worked example Squashed fault: ek branch mispredicted hai; wrong path par speculatively-fetched

LW fault karta hai Pipeline ne branch outcome guess kiya aur aage bhaagi. Wrong (mispredicted) path par ek LW hai jo page-fault karega. Baad mein branch resolve hota hai — guess galat tha.

Forecast: kya OS kabhi yeh page fault dekhta hai?

Trap-door pehchano. Ek fault tabhi real hoti hai jab faulting instruction commit tak pahunche (yahi rule humne upar define kiya). Speculative instructions committed nahi hui hain. Kyun? Architectural state sirf commit par change hoti hai; usse pehle, sab kuch provisional microarchitectural state hai.
Squash karo. Jab branch wrong resolve hota hai, LW aur saara wrong-path kaam squash ho jaata hai (discard — dekho Pipelining and Hazards). Iska page fault uske saath discard ho jaata hai. Kyun? Sequential model mein woh LW kabhi execute nahi hua — toh uski fault kabhi visible nahi honi chahiye.
Result. Koi exception report nahi hoti. OS ko kabhi nahi bataya jaata. Kyun? Ek instruction ka fault report karna jo "kabhi chali hi nahi" precise semantics violate karega.

Verify: Ex 1 se compare karo: identical LW page fault, lekin yahan woh squashed path par hai, toh "exception reported" yes se no flip ho jaata hai. Deciding factor hamesha yeh hai: kya yeh committed hua?

Ex 8 — Cell H · Word problem (chained rules, real trace)

Worked example Ek

write() call jo ek missing page bhi cross karta hai Ek program order mein yeh chalata hai:

Addr	Instr	Note
`0x8000`	`LW R1, 0(R2)`	ek byte-count load karta hai, page present
`0x8004`	`LW R3, 0(R4)`	page not resident
`0x8008`	`SYSCALL`	`write()` request karta hai

Forecast: pehli exception kya hai, uska EPC kya hai, aur sab resolve hone aur syscall complete hone ke baad final EPC kya hai?

Pehli instruction (0x8000). Normally commit karti hai; R1 likhaa jaata hai; PC advance hota hai. Yahan se kyun start karein? Precision zaroori karti hai ki older instructions fully committed hoon pehle kisi baad ki fault ke report hone se.
Doosri instruction (0x8004). Page fault → fault → $E P C = 0 x 8004$ (retry). Syscall tak kyun skip nahi karein? LW older hai; uska un-committed fault boundary ka malik hai (Ex 5 rule).
OS handle karta hai, 0x8004 par restart. Page ab present hai; R3 load aur commit hota hai; PC 0x8008 tak advance hota hai. Poora LW dobara kyun run karein? Fault semantics = faulting instruction retry karo (Ex 1).
Teesri instruction (0x8008). SYSCALL → trap → servicing ke baad, resume karo $E P C = 0 x 8008 + 4 = 0 x 800 C$ par. Kyun $+ 4$ ? Syscall ne apna kaam committed kiya; iske aage continue karo (Ex 2).

Verify: Pehli reported exception EPC $= 0 x 8004 = 32772$ (fault). Trap ke baad final resume EPC $= 0 x 8008 + 4 = 0 x 800 C = 32780$ . Do alag EPC rules ek hi trace mein sahi tarike se chained.

Ex 9 — Cell I · Exam twist: faulting instruction khud ek branch hai

Worked example Limiting case: ek taken branch

BEQ R1,R2,offset 0x9000 par fault bhi trigger karta hai Maano branch taken hai (toh woh PC ← 0x9000 + 4 + 4·offset set karna chahta hai) lekin wahi instruction commit hone se pehle fault raise karti hai, offset = 5 ke saath.

Forecast: kya EPC branch target use karta hai ya branch ki apni address?

Compute karo ki branch kya karta. Taken target $= 0 x 9000 + 4 + 4 \cdot 5 = 0 x 9000 + 24 = 0 x 9018$ . Yeh kyun compute karein? Dikhane ke liye ki yeh target sirf tabhi reach hota hai jab branch commits.
Fault rule apply karo. Ek fault ka matlab hai instruction committed nahi ⇒ uska PC-update kabhi nahi hua. Toh $E P C = 0 x 9000$ — branch ki apni address, not target. Kyun? Fault = faulting instruction ko scratch se retry karo. Branch ne abhi architecturally kuch decide nahi kiya.
OS cause fix karke 0x9000 par return karne ke baad, branch re-execute hota hai, ab commit karta hai, aur tab PC ko 0x9018 set karta hai. Kyun? Branch ki semantics (uska PC-write shamil hai) sirf ek clean, committed run par effect mein aate hain.

Verify: Would-be target $0 x 9000 + 4 + 4 \cdot 5 = 0 x 9018 = 36888$ , lekin $E P C = 0 x 9000 = 36864$ kyunki ek faulting branch ne apna PC-write kabhi committed nahi kiya. Twist yeh hai: sabse tempting answer (target) exactly galat answer hai.

Wrap-up recall

Recall Ek question se poora matrix reconstruct karo

"Kya instruction committed hui, aur kya woh khatam karna chahti thi?" Fault (committed nahi, retry karna zaroori) → EPC ::: faulting instruction ki address Trap (apna kaam committed kiya) → EPC ::: next instruction ki address Abort (uncorrectable) → EPC ::: koi nahi; process killed Interrupt (external, cleanly paused, maskable) → EPC ::: next uncommitted instruction Squashed speculative fault → reported? ::: kabhi nahi — yeh committed hi nahi hua Do faults same cycle → kaun sa report karein? ::: program-order-oldest wala Interrupt + exception same cycle → kaun jeeega? ::: synchronous exception (interrupt pending rehta hai)

Parent topic par wापas jaao · yeh poora page hardware–software contract ka practical face hai.