Instruction-level semantics and exceptions: Question bank

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

Shuru karne se pehle, yeh words apne dimaag mein solid kar lo, kyunki har question inhi par tikaa hai:

Recall Vocabulary refresher (sirf tab kholo jab neeche koi term shaky lage)

Architectural state = woh machine parts jo ek programmer dekh sakta hai: registers, program counter (PC), flags, memory.
Microarchitectural state = chuppe hue implementation parts: pipeline latches, caches, reorder buffer.
Commit / retire = woh moment jab ek instruction ka result architectural state mein visible ho jaata hai; yeh strictly program order mein hota hai.
Precise exception = jab handler shuru hota hai, fault se pehle ki har cheez complete ho chuki hoti hai aur uske baad ki koi cheez architectural state ko touch nahi karti.
Fault usi same instruction par return karta hai; trap next par return karta hai; abort return hi nahi karta.

True ya false — justify karo

True ya false: Sequential execution model mein, ek instruction kisi baad wali instruction ka result dekh sakti hai jo same register mein likhti hai.

False. Model strictly program order mein hai, isliye ek read sirf pehle ki writes dekhta hai; hardware overlap reader ke liye invisible hota hai.

True ya false: Ek branch instruction ka fundamentally alag semantics hota hai ek ADD se — bilkul alag skeleton.

False. Yeh wahi read–compute–write–update-PC skeleton hai; sirf PC-update rule (step 4) override hota hai, baaki sab unchanged rehta hai.

True ya false: Kyunki ek real CPU out-of-order execute karta hai, uske exceptions inherently imprecise hote hain.

False. Out-of-order execution internally hoti hai, lekin commit stage in-order visibility enforce karta hai, isliye architectural state har exception par precise rehti hai.

True ya false: PC ← PC + 4 ek optional bookkeeping detail hai, instruction ke meaning ka hissa nahi.

False. PC ko update karna semantics ka hissa hai — ek instruction jo result compute kare lekin PC kabhi advance na kare, woh khud par loop karta rahega.

True ya false: Har exception state save karta hai aur handler par jump karta hai, isliye exceptions aur interrupts basically same mechanism hain.

False, us sense mein jo matter karta hai. Mechanism similar lagta hai, lekin exceptions synchronous hote hain (instruction stream ka deterministic function) jabki interrupts asynchronous hote hain (external timing), aur yahi difference restartability decide karta hai.

True ya false: Agar tum ek program same inputs ke saath dobara chalao, tumhe same exceptions milenge lekin necessarily same interrupts nahi.

True. Exceptions instruction stream ki wajah se hote hain isliye exactly reproduce hote hain; interrupts external device timing par depend karte hain aur generally reproduce nahi hote.

True ya false: Ek trap aur ek fault mein sirf itna fark hota hai ki handler kis PC par return karta hai.

True in essence. Dono handler ko control transfer karte hain; deciding difference yeh hai ki fault same instruction re-run karta hai (EPC = woh instruction) aur trap next par resume karta hai (EPC = instruction + length).

True ya false: Exception par younger instructions ko squash karna architectural state ko corrupt kar sakta hai.

False. Squashed instructions kabhi committed nahi hue, isliye unke results sirf microarchitectural state mein the; unhe discard karne se architectural state untouched rehti hai.

True ya false: Ek ABORT-class exception ko safely retry kiya ja sakta hai jab OS cause clear kar de.

False. Aborts unrecoverable hardware errors signal karte hain (jaise corrupted memory); return karne ke liye koi clean state nahi hai, isliye program restart nahi ho sakta.

Error dhundho

"Ek page fault handler ko faulting load ke baad wali instruction par return karna chahiye, kyunki fault ab resolve ho gaya hai." — error dhundho.

Galat return point. Faulting load ne actually apna data kabhi fetch nahi kiya (state precise rakhi gayi thi, isliye R5 untouched tha); handler ko usi load par return karna chahiye taaki woh actually execute ho sake.

"syscall par, OS handler syscall instruction par hi return karta hai." — error dhundho.

syscall ek trap hai — woh apna kaam kar chuka hai (service request ki). Uspar return karna request dobara issue karta hai; correct EPC next instruction hai.

"Jab do instructions same cycle mein fault karein, jo hardware pehle detect kare usse report karo." — error dhundho.

Detection timing ek microarchitectural accident hai. Precise semantics ke liye program-order-oldest fault report karna zaroori hai, kyunki reported fault se pehle ki har cheez complete appear honi chahiye.

"Kyunki caches aur branch predictors CPU ka hissa hain, software unki state par depend kar sakta hai." — error dhundho.

Caches aur predictors microarchitectural hain. ISA contract sirf architectural state guarantee karta hai; hidden state par depend karna tab break ho jaata jab vendor internals redesign kare.

"Exceptions precise banane ke liye, bas fault detect hote hi instructions execute karna band karo." — error dhundho.

Rukna kaafi nahi. Tumhe older instructions ko commit bhi karne dena hoga aur younger ones jo already in flight hain unhe squash karna hoga; sirf ruk jaane se kisi younger instruction ki write already committed ho sakti hai.

"BEQ ek register likhta hai, isliye uske semantics mein step 3 mein ek register write shaamil hai." — error dhundho.

BEQ koi general-purpose register nahi likhta; R1, R2 padhne ke baad uska sirf PC-update rule effect hota hai. Write step yahaan empty hai.

Why questions

Architectural aur microarchitectural state ko alag kyun rakhna zaroori hai?

Taaki ISA ek stable contract ki tarah kaam kare: software sirf architectural state par depend karta hai, jisse vendors internals redesign kar sakein (deeper pipelines, out-of-order execution) bina compiled programs todhe.

Precise exception ke liye zaroori kyun hai ki faulting instruction par ya uske baad kuch bhi architectural state modify na kare?

Taaki OS cause fix karke resume kar sake jaise machine ek instruction boundary par cleanly pause hui ho; ek half-executed younger instruction us state ko pollute kar deti jise handler rewind karne ki koshish kar raha hai.

Ek fault "restartable" kyun hai lekin abort nahi?

Fault ek correctable condition hai jo commit se pehle detect hoti hai, isliye exact same instruction fix ke baad rerun ho sakta hai; abort ek unrecoverable hardware failure reflect karta hai jisme return karne ke liye koi clean state nahi.

Instructions commit kyun karte hain program order mein jabki execute out of order karte hain?

In-order commit hi woh cheez hai jo visible state ko sequential model se match karaati hai; execution order optimise karne ke liye free hai jab tak retire stage ek-ek karke, in-order updates ka illusion restore kare.

Exception PC (EPC) save kyun kiya jaata hai normal PC par rely karne ki jagah?

Jab pipeline squash karke handler par jump karta hai, normal PC vector address se overwrite ho jaata hai; EPC wahan preserve karta hai jahan return karna hai, jo faults (same instruction) aur traps (next instruction) ke liye alag hota hai.

Same program input hamesha same exception reproduce kyun karta hai lekin same interrupt nahi?

Exceptions instruction stream ka deterministic function hain (synchronous), jabki interrupts external devices se aate hain jinki timing program se independent hai (asynchronous).

Ek instruction ko state transition function

state_{n + 1} = execute (instr, state_{n})

ke roop mein describe karna uska poora meaning kyun capture karta hai?

Kyunki ek instruction jo kuch bhi kar sakti hai woh inputs padhne, compute karne, outputs likhne, aur PC update karne tak reduce ho jaata hai — yeh sab bas old architectural state se new state ka ek mapping hai.

Edge cases

Edge case: Ek syscall execute hoti hai, OS usse service karta hai, aur control return hoti hai — kis PC par, aur same par kyun nahi?

syscall_address + 4 par (next instruction). Trap hone ki wajah se usne apna meaning complete kar liya; uspar return karna request dobara issue kar deta.

Edge case: Instruction

I_{1}

(div-by-zero) aur

I_{3}

(page fault) dono same cycle mein raise hote hain — kaunsa exception report hoga?

I_{1}

ka, kyunki woh program-order mein pehle hai. Sequential world mein

I_{3}

ki fault "abhi hui nahi hai," isliye precise semantics demand karti hai ki oldest fault jeetey.

Edge case: Ek speculatively-executed instruction jo mispredicted branch path par hai, page fault raise karti hai — kya OS involve hoga?

Nahi. Woh instruction wrong path par hai aur commit se pehle squash ho jaayegi, isliye uska "fault" architecturally visible kabhi nahi hota aur koi handler invoke nahi hota.

Edge case: Ek interrupt (asynchronous) mid-pipeline aata hai — CPU phir bhi exceptions precise kaise rakhta hai?

Woh interrupt ko ek instruction boundary se attach karta hai: kuch chosen commit point tak instructions retire hone deta hai, baaki ko squash karta hai, phir interrupt precisely leta hai jaise yeh do committed instructions ke beech hua ho.

Edge case: Ek instruction read aur write dono same register pe karti hai (jaise R1 ← R1 + R3) — kya read new value dekhta hai?

Nahi. Semantically R1 ka read old architectural state par hota hai; write new value sirf baad wali instructions ke liye produce karta hai, kabhi apne read ke liye nahi.

Edge case: Ek BEQ taken branch ke saath fault karti hai bilkul next fetched instruction par — fault kis instruction ko attributed hogi?

Us fetched target instruction ko jo actually fault ki, branch ko nahi; branch cleanly commit ho gaya, isliye precise state mein uska PC update include hai, aur EPC faulting target ko point karta hai.

Recall One-line self-test

Woh single fact jo kisi bhi exception ke liye return-PC determine karta hai woh hai... ::: kya yeh fault hai (return same instruction par) ya trap (return next par).

See also: Pipelining and Hazards · Out-of-Order Execution and the Reorder Buffer · Virtual Memory and Page Faults · System Calls and Privilege Levels · Interrupts and I/O · ISA as a Hardware–Software Contract