Instruction-level semantics and exceptions: Visual walkthrough

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

Step 1 — "Ek time par ek instruction" actually kaisa dikhta hai

WHAT. Ek factory conveyor belt imagine karo. Belt par har box ek instruction hai — ek single command jo CPU maanta hai, jaise "yeh do numbers add karo" ya "memory se yeh value load karo". Yeh left side se program order mein enter karte hain (woh order jismein tumne unhe likha) aur ek ke baad ek right side par finish hone chahiye.

WHY. Isse pehle ki hum kuch galat hone ki baat karein, hume yeh nail down karna hoga ki "sahi hona" ka matlab kya hai. CPU promise karta hai ki visible state — woh values jo ek programmer wapas read kar sakta hai — hamesha aise dikhti hai jaise boxes strictly left-to-right, poori tarah, ek box ke baad doosra shuru ho. Hum ise sequential execution model kehte hain. Yeh woh yardstick hai jiske against baaki sab kuch measure hota hai.

PICTURE. Belt par chaar boxes $I_{1}, I_{2}, I_{3}, I_{4}$ . "Program order" woh arrow hai jo right taraf point karta hai.

Yahan

I_{k}

program order mein

k

-th instruction (

k

number ka belt box)

"Visible state aise dikhti hai jaise boxes left-to-right chale" iska naam hai

sequential execution model

Step 2 — Har box ek chhote rule se state change karta hai

WHAT. Har box zyada se zyada chaar kaam karta hai: kuch inputs read karna, ek result compute karna, ek output write karna, aur $P C$ update karna (agla box choose karna). Hum ise ek state-transition ke roop mein likhte hain:

$box n ke baad ki state state_{n + 1} = rule execute (yeh box instr, pehle ki state state_{n})$

Term by term: $state_{n}$ woh sab kuch hai jo box se pehle visible hai; $instr$ box ka command hai; $execute$ box-specific rule hai; $state_{n + 1}$ woh sab kuch hai jo baad mein visible hai.

WHY. Agar har box sirf ek rule hai jo "state before" ko "state after" mein map karta hai, to poora program woh rules hain jo order mein composed hain. Woh composition hi Step 1 ki promise hai, maths mein likhi hui.

PICTURE. Ek box $I_{2}$ ek input slot ke saath (state $_{1}$ andar flow kar rahi hai) aur ek output slot ke saath (state $_{2}$ bahar flow kar rahi hai), upar chhota rule stamped hai.

Step 3 — Mushkil: boxes actually ek time par process nahi hote

WHAT. Real hardware impatient hota hai. Fast jaane ke liye yeh ek saath kaafi boxes par kaam karta hai (ek pipeline) aur koi baad wala box ek pehle wale box se pehle finish bhi ho sakta hai (out-of-order execution). To machine ke andar, belt ek blur hai — boxes overlap karte hain aur ek doosre ko overtake bhi karte hain.

WHY show this. Kyunki yeh Step 1 ko tod deta lagta hai! Agar $I_{3}$ apna computation $I_{1}$ se pehle finish kar le, to visible state kaisi left-to-right dikh sakti hai? Hume is tension ko resolve karna hoga, aur resolution hi is page ka pura point hai.

PICTURE. Wahi chaar boxes, ab overlapping pipeline stages mein stacked hain, $I_{3}$ ka compute pehle se done hai jabki $I_{1}$ abhi kaam kar raha hai — ek arrow dikhata hai $I_{3}$ "overtake" kar raha hai.

Woh trick jo promise bachati hai

results out of order compute hote hain par sirf order mein visible hote hain

Step 4 — Rescue: freely compute karo, par strictly in order commit karo

WHAT. Hum ek box ki zindagi ko do moments mein split karte hain. Execute = arithmetic karo / cache touch karo (kisi bhi time, kisi bhi order mein ho sakta hai). Commit (isko retire bhi kehte hain) = woh instant jab result ko visible architectural state change karne ki permission milti hai. Rule yeh hai:

$commit order = program order (I_{1} pehle I_{2} pehle I_{3} \dots)$

WHY. Jo reader visible state dekh raha hai woh sirf commits dekhta hai, aur commits left-to-right chalte hain. To bahar se bilkul sequential dikhta hai jabki andar chaos hai. Waiting-room (reorder buffer) finished results tab tak hold karta hai jab tak unki commit hone ki baari nahi aa jaati.

PICTURE. Do lanes: upar ek scrambled "executed" lane, aur neeche ek tidy in-order "commit gate" jo boxes ko ek at a time, oldest first, through karne deta hai.

Step 5 — Ab kuch galat hota hai: ek box par exception

WHAT. Maan lo box $I_{3}$ ek load hai, LW R5, 0(R6), aur jis page ki use zaroorat hai woh memory mein nahi hai — ek page fault. Yeh $I_{3}$ ke execution ke dauran detect hota hai, $I_{3}$ ke commit se pehle.

WHY yahan. Exception ek unexpected transfer of control hai belt se door: OS ko step in karna hoga. Par OS tab hi help kar sakta hai jab use ek clean machine diya jaaye. "Clean" ka matlab hum aage define karenge; yeh step sirf guilty box mark karta hai.

PICTURE. Belt jisme $I_{3}$ red ⚡ fault marker flash kar raha hai, $I_{1}, I_{2}$ safely uske left par, $I_{4}$ uske right par.

Fault ke waqt

R 5

abhi bhi apni purani value hold karta hai —

I_{3}

commit nahi hua, isliye usne kuch likha nahi

Step 6 — Clean stopping point: ek precise exception

WHAT. Hardware ab ek razor-sharp picture enforce karta hai:

$I_{3}$ se pehle har box (yani $I_{1}, I_{2}$ ) poori tarah commit ho chuka hai — unke results visible hain.
$I_{3}$ aur uske baad har box ( $I_{4}, \dots$ ) squash ho jaate hain: unke computed results throw away ho jaate hain aur kabhi visible state tak nahi pahunchte.

$visible state at handler start = exactly the sequential state right before I_{3}$

Term by term: left side woh hai jo OS dekhta hai; right side woh tidy left-to-right state hai jaise belt $I_{2}$ aur $I_{3}$ ke beech boundary par cleanly ruk gayi ho.

WHY. Yahi recovery possible banata hai. Page-fault handler missing page load kar sakta hai aur phir keh sakta hai "ek baar aur $I_{3}$ run karo" — aur kyunki $I_{3}$ ne kuch bhi change nahi kiya, ise re-run karna safe aur correct hai. Agar baad ka box $I_{4}$ pehle se kisi register ko pollute kar chuka hota, to restart karna impossible hota.

PICTURE. Belt ek clean vertical "commit boundary" line se cut hai: green (committed) $I_{1}, I_{2}$ left par, greyed-out squashed $I_{3}, I_{4}$ right par, boundary par arrow jisme "clean state" label hai.

Step 7 — Handler kaun se address par return karta hai? (fault vs trap)

WHAT. EPC (Step 5) exception ke type se choose hota hai. Do cases:

Fault (e.g. page fault): box apna meaning finish nahi kar paya. Same box par return karo. $E P C = address of the faulting box$
Trap (e.g. syscall): box apna meaning finish kar chuka tha (usne purpose se service maangi thi). Agle box par return karo. $E P C = address of the box + 4$

Term by term: $+ 4$ ek box-width hai, to " $+ 4$ " literally matlab hai "belt par agla box".

WHY. Fault kehta hai "mujhe dobara try karo" — OS cause fix kare tab retry karo. Trap kehta hai "maine apna kaam kar diya, aage bado" — ise dobara run karna request double kar dega. Dono families mein poora fark yahi ek return address choice hai.

PICTURE. Do chhoti belts side by side: ek fault belt jisme return arrow same red box par curve karta hai; ek trap belt jisme return arrow next box par land karta hai.

Dekho System Calls and Privilege Levels ki trap OS ko control kaise deta hai, aur Interrupts and I/O exceptions ke asynchronous cousin ke liye.

Step 8 — Same cycle mein do exceptions: oldest jeet ta hai

WHAT. Maan lo $I_{1}$ mein divide-by-zero hai aur $I_{3}$ mein page fault hai, dono same cycle mein spot hue. Hardware oldest (program order mein earliest) faulting box ka exception report karta hai — yahan $I_{1}$ .

WHY. Precise semantics (Step 6) demand karta hai ki reported fault se pehle sab kuch commit ho chuka ho. Tidy left-to-right world mein, $I_{1}$ , $I_{3}$ se pehle aata hai, isliye belt $I_{1}$ par already "ruk" chuki honi chahiye thi — $I_{3}$ ka fault abhi hona hi nahi chahiye tha. $I_{1}$ report karna fiction ko consistent rakhta hai.

PICTURE. Belt par $I_{1}$ (magenta) aur $I_{3}$ (orange) par do ⚡ markers; $I_{1}$ par crown jisme label hai "reported — oldest wins", $I_{3}$ greyed aur squashed.

Ek-picture summary

Upar sab kuch ek single frame mein: boxes left se program order mein flow karte hain; woh ek scrambled inner lane mein execute hote hain; ek commit gate unhe serialize karta hai; box $I_{3}$ fault karta hai; ek clean boundary $I_{1}, I_{2}$ ko committed freeze karti hai aur $I_{3}, I_{4}$ ko squash karti hai; handler vector par enter hota hai EPC ke saath jo $I_{3}$ (fault) par ya $I_{4}$ (trap) par wapas point karta hai.

Recall Feynman retelling — simple words mein bolo

Ek kitchen imagine karo. Tickets (instructions) order mein aate hain. Cooks dishes ko jis order mein fastest ho sake prepare karte hain, par ek single serving hatch dishes strictly ticket order mein bahar bheji hai — isliye diners hamesha ek orderly meal dekhte hain chahe kitchen chaos ho. Ek din ek dish finish nahi ho sakti kyunki ek ingredient missing hai (ek page fault). Rule yeh hai: us ticket se pehle sab kuch already serve ho chuka hai, aur woh ticket aur uske baad sab kuch bin mein jaata hai — untouched, jaise kabhi shuru hi nahi hua. Manager (OS) ko front door (vector) par bulaya jaata hai aur ek note (EPC) diya jaata hai jo batata hai kahaan resume karna hai: missing ingredient ke liye hum same dish retry karte hain (fault ⇒ same address); ek customer ke liye jisne kuch maanga aur mila, hum agli dish par move karte hain (trap ⇒ address + 4). Agar do dishes ek saath fail hon, to hum earlier ticket wale ko blame karte hain, kyunki orderly world mein uska failure pehle hota hai. Woh single hatch — program order mein commit — hi woh poori trick hai jo exceptions ko precise aur programs ko restartable banati hai.

Recall Quick self-test

Fault kaun se address par return karta hai? ::: same faulting instruction par ( $E P C =$ uska apna address) Trap kaun se address par return karta hai? ::: agla instruction ( $E P C =$ address $+ 4$ ) LW R5,... par page fault ke baad $R 5$ safely retry kyun ho sakta hai? ::: load kabhi commit nahi hua, isliye $R 5$ unchanged hai Kaunsa single mechanism exceptions ko precise banata hai? ::: in-order commit/retire, out-of-order execution ke bawajood Same cycle ke do faults — kaun report hota hai? ::: program order mein oldest

Prev / context: yeh deep dive parent ki precise exception result expand karta hai topic note, aur is idea par rely karta hai ki ISA as a Hardware–Software Contract sequential model guarantee karta hai implementation se independent hoke.