Exercises — Instruction-level semantics and exceptions

Fault return PC ::: the same instruction (restart it) Trap return PC ::: the next instruction (it already did its job)

1. Trap — deliberate, program asked for the service; resume after it.
2. Fault — correctable, detected before the load writes; restart the same load.
3. Interrupt — external device, asynchronous, unrelated to the current arithmetic.
4. Abort — unrecoverable hardware error; the program cannot continue.
5. Fault — detected before commit; div-by-zero is correctable by the OS (e.g. signal a handler), and it is synchronous (same inputs reproduce it).

• R4 — Architectural (programmer-visible register).
• Branch predictor table — Microarchitectural (pure speed hint, no ISA meaning).
• PC — Architectural (defined by every instruction's semantics).
• Reorder buffer — Microarchitectural (bookkeeping for in-order commit).
• Data cache line — Microarchitectural (a copy of memory; the ISA defines memory, not the cache).
• Carry flag — Architectural (a status flag the ISA specifies).

The test: Could Intel remove or redesign it without breaking your compiled program? If yes → microarchitectural. If no → architectural. See ISA as a Hardware–Software Contract.

The semantics is $R1\leftarrow R2+R3,PC\leftarrow PC+4$.

• $R1=10+7=17$.
• $PC=0x1000+4=0x1004$.

The PC update is part of the instruction's meaning — an instruction that computed but forgot to advance the PC would execute forever.

$PC\leftarrow \{\begin{array}{ll}PC+4+4\cdot \text{offset}& R1=R2\\ PC+4& \text{otherwise}\end{array}$ (a) Equal ⇒ taken: $0x2000+4+4\cdot 3=0x2000+16=0x2010$. (b) Not equal ⇒ fall through: $0x2000+4=0x2004$.

Notice the only thing a branch changes versus ADD is the PC-write rule — same read/compute skeleton, different step 4. See Pipelining and Hazards for why branches are expensive.

syscall is a trap: it already performed its meaning (it lodged the OS request). We resume at the next instruction, so $EPC=0x8040+4=0x8044$. Returning to $0x8040$ would re-issue the same request twice. See System Calls and Privilege Levels.

A page fault is a fault: it is detected before the load commits, so $R5$ is unchanged (precise-exception rule 2). $EPC=0x8060$ — the address of the LW itself — because after the OS brings the page in, the same load must run again to actually deliver the data. See Virtual Memory and Page Faults.

Report the oldest faulting instruction in program order ⇒ $I_2$ (div-by-zero).

• $I_1$ must have fully committed (it is older than the reported fault ⇒ precise rule 1).
• $I_2$ and everything younger ($I_3,I_4$) must not have modified architectural state (rule 2).
• $I_4$'s page fault is discarded — in the clean sequential world execution never reached $I_4$, because it should have stopped at $I_2$. If the OS re-runs $I_2$ and it faults again after the fix, only then will $I_4$ get its chance. See Out-of-Order Execution and the Reorder Buffer.

Instructions may compute out of order, but they commit (retire) — become architecturally visible — strictly in program order, at the commit/retire stage fed by the reorder buffer. A younger instruction's result sits in the buffer, invisible, until every older instruction has retired. When a fault is detected, the hardware squashes the faulting instruction and everything younger (their buffered results are thrown away) and lets older ones retire. So the visible state is always exactly the clean sequential state at some instruction boundary.

The page fault is guaranteed identical: exceptions are synchronous — a deterministic function of the instruction stream and data, so the same inputs reproduce it at #500 every time. The timer interrupt is asynchronous — driven by external wall-clock timing, not the program. On the second run it may land at a different instruction, or not fire in that window at all. See Interrupts and I/O.

The figure below draws the same three-row timeline described in words here — read the text first, then use the picture to check yourself.

1. $0x300$ ADD commits. It is older than the fault, so it fully updates $R1$. (Top row, drawn in chalk blue — "commits (older)".)
2. $0x304$ LW faults. The page is absent. Detected before commit ⇒ $R5$ is not written. (Middle row, chalk pink — "FAULT (page absent)".)
3. $0x308$ SUB is squashed. It is younger than the fault; even if it already computed something speculatively, that result is discarded — $R7$ is untouched. (Bottom row, plain chalk — "squashed (younger)".) Good thing: it depends on $R5$, which the fault left stale.
4. Save state. $EPC=0x304$ (the LW's own address, because it is a fault), plus the cause and the faulting virtual address. (The pale-yellow curved arrow in the figure points from the saved state back to $0x304$.)
5. OS handler runs. It brings the missing page into physical memory (see Virtual Memory and Page Faults), updates the page table, and returns to $EPC$.
6. Resume at $0x304$. The LW re-executes, this time hits a present page, writes $R5$, and execution flows on to SUB at $0x308$ normally.

Net effect: the program never notices anything except a time delay — the promise "execute in order, completely" is kept.

• syscall is a trap ⇒ resume at the next instruction: $PC=0x500+4=0x504$.
• The OS did the requested work and deliberately wrote the result into the architectural register $R2$ (this is the trap "completing its meaning"). So $R2$ now holds the time value the OS supplied.
• Contrast with a fault: a fault handler does not leave a return value in the faulting register — it fixes the environment and re-runs the same instruction, which then produces the value itself.

A clean, defensible policy: finish resolving the synchronous exception's instruction boundary first, then take the interrupt. Concretely — squash $I_2$ and younger, save $EPC=$ address of $I_2$ for the fault, and take the fault handler. The interrupt is asynchronous: it is not tied to any particular instruction, so it is fine to service it slightly later (many designs take it at the very next clean commit boundary, which the fault handling just created). The key correctness rule: whichever we take, the saved EPC must point at a precise instruction boundary so both handlers can return cleanly. (Real ISAs specify an exact priority table; the principle — precision preserved either way — is what matters.)

1. $R1=12$. Semantics are atomic per instruction: the read of both source operands happens on the old value ($6$), the write happens after ($6+6=12$). The sequential model forbids the write from feeding back into this instruction's own read.
2. Taken target $=PC+4+4\cdot 0=PC+4$ — the same address as falling through. An offset-0 taken branch simply lands on the next instruction; it is a legal but pointless jump.
3. $EPC=0x700+4=0x704$ (it is a trap, resume at next). On return the PC points into the unmapped page, so fetching the instruction at $0x704$ itself page-faults. That is a separate, later fault — an instruction-fetch page fault — handled entirely on its own. The trap's return was still correct; the machine simply raises a fresh, distinct exception immediately. Two distinct events, each resolved at its own precise boundary, one at a time.

Software depends only on architectural state behaving as if instructions ran one-by-one in order; the ISA guarantees exactly that. So the vendor can redesign all microarchitecture — deeper pipelines, out-of-order execution, speculation — and as long as commit stays in-order and exceptions stay precise, your old binary sees the identical visible results, just faster. This is the whole point of the ISA as a Hardware–Software Contract.

Fault return PC vs trap return PC ::: fault → same instruction; trap → next instruction Which exception is reported among several ::: the oldest in program order What enforces precise exceptions in an out-of-order CPU ::: in-order commit/retire (reorder buffer) Synchronous vs asynchronous ::: exception = caused by instruction stream; interrupt = external timing ADD R1, R1, R1 with R1=6 ::: 12 (read-before-write, atomic) What does EPC hold ::: the return address bookmarked when an exception fires