5.1.12 · D5Instruction Set Architecture (ISA)
Question bank — Instruction-level semantics and exceptions
Before you start, make sure these words are solid in your head, because every question leans on them:
Recall Vocabulary refresher (open only if a term below feels shaky)
- Architectural state = the machine parts a programmer can see: registers, program counter (PC), flags, memory.
- Microarchitectural state = hidden implementation parts: pipeline latches, caches, the reorder buffer.
- Commit / retire = the moment an instruction's result becomes visible in architectural state; happens strictly in program order.
- Precise exception = when the handler starts, everything before the fault has completed and nothing at or after it has touched architectural state.
- Fault returns to the same instruction; trap returns to the next; abort does not return.
True or false — justify
True or false: In the sequential execution model, an instruction may see the result of a later instruction that writes the same register.
False. The model is strictly in program order, so a read only ever sees writes from earlier instructions; hardware overlap is invisible to the reader.
True or false: A branch instruction has fundamentally different semantics from an ADD — a whole separate skeleton.
False. It's the same read–compute–write–update-PC skeleton; only the PC-update rule (step 4) is overridden, everything else is unchanged.
True or false: Because a real CPU executes out of order, its exceptions are inherently imprecise.
False. Out-of-order execution happens internally, but the commit stage forces in-order visibility, so architectural state stays precise at every exception.
True or false: PC ← PC + 4 is an optional bookkeeping detail, not part of an instruction's meaning.
False. Updating the PC is part of the semantics — an instruction that computed a result but never advanced the PC would loop on itself forever.
True or false: Every exception saves state and jumps to a handler, so exceptions and interrupts are really the same mechanism.
False in the sense that matters. The mechanism looks similar, but exceptions are synchronous (a deterministic function of the instruction stream) while interrupts are asynchronous (external timing), and that difference decides restartability.
True or false: If you re-run a program with the same inputs, you get the same exceptions but not necessarily the same interrupts.
True. Exceptions are caused by the instruction stream itself so they reproduce exactly; interrupts depend on external device timing and generally do not.
True or false: A trap and a fault can differ only in which PC the handler returns to.
True in essence. Both transfer control to a handler; the deciding difference is that a fault re-runs the same instruction (EPC = the instruction) and a trap resumes at the next one (EPC = instruction + length).
True or false: Squashing younger instructions on an exception can corrupt architectural state.
False. Squashed instructions never committed, so their results existed only in microarchitectural state; discarding them leaves architectural state untouched.
True or false: An ABORT-class exception can be safely retried once the OS clears the cause.
False. Aborts signal unrecoverable hardware errors (e.g. corrupted memory); there is no clean state to return to, so the program cannot be restarted.
Spot the error
"A page fault handler should return to the instruction after the faulting load, since the fault is now resolved." — spot the error.
Wrong return point. The faulting load never actually fetched its data (state was kept precise, so
R5 was untouched); the handler must return to the same load so it can execute for real."On a syscall, the OS handler returns to the syscall instruction itself." — spot the error.
syscall is a trap — it already did its job (requested service). Returning to it re-issues the request; the correct EPC is the next instruction."When two instructions fault in the same cycle, report whichever the hardware detects first." — spot the error.
Detection timing is a microarchitectural accident. Precise semantics requires reporting the program-order-oldest fault, because everything before the reported fault must appear to have completed.
"Since caches and branch predictors are part of the CPU, software can depend on their state." — spot the error.
Caches and predictors are microarchitectural. The ISA contract only guarantees architectural state; depending on hidden state would break the moment the vendor redesigns the internals.
"To make exceptions precise, just stop executing instructions the moment a fault is detected." — spot the error.
Stopping isn't enough. You must also let older instructions commit and squash younger ones already in flight; merely halting could leave a younger instruction's write already committed.
"BEQ writes a register, so its semantics include a register write in step 3." — spot the error.
BEQ writes no general-purpose register; its only effect beyond reading R1, R2 is the PC-update rule. The write step is empty here.Why questions
Why must architectural and microarchitectural state be separated at all?
So the ISA acts as a stable contract: software depends only on architectural state, letting vendors redesign the internals (deeper pipelines, out-of-order execution) without breaking compiled programs.
Why does a precise exception require that nothing at or after the faulting instruction has modified architectural state?
So the OS can fix the cause and resume as if the machine paused cleanly on one instruction boundary; a half-executed younger instruction would pollute the state the handler is trying to rewind to.
Why is a fault "restartable" but an abort is not?
A fault is a correctable condition detected before commit, so the exact same instruction can rerun after the fix; an abort reflects an unrecoverable hardware failure with no clean state to return to.
Why do instructions commit in program order even when they execute out of order?
In-order commit is what makes the visible state match the sequential model; execution order is free to be optimised as long as the retire stage restores the illusion of one-at-a-time, in-order updates.
Why is the exception PC (EPC) saved rather than just relying on the normal PC?
When the pipeline squashes and jumps to the handler, the normal PC is overwritten by the vector address; the EPC preserves where to return, which differs for faults (same instruction) versus traps (next instruction).
Why can the same program input always reproduce the same exception but not the same interrupt?
Exceptions are a deterministic function of the instruction stream (synchronous), while interrupts arrive from external devices whose timing is independent of the program (asynchronous).
Why does describing an instruction as a state transition function capture all of its meaning?
Because everything an instruction can do reduces to reading inputs, computing, writing outputs, and updating the PC — all of which are just a mapping from the old architectural state to the new one.
Edge cases
Edge case: A syscall executes, the OS services it, and control returns — at which PC, and why not the same one?
At
syscall_address + 4 (the next instruction). As a trap it already completed its meaning; returning to it would issue the request twice.Edge case: Instruction (div-by-zero) and (page fault) both raise in the same cycle — which exception is reported?
's, because it is program-order-earlier. In the sequential world 's fault "hasn't happened yet," so precise semantics demands the oldest fault win.
Edge case: A speculatively-executed instruction on a mispredicted branch path hits a page fault — does the OS get involved?
No. That instruction lies on a wrong path and will be squashed before commit, so its "fault" never becomes architecturally visible and no handler is invoked.
Edge case: An interrupt (asynchronous) arrives mid-pipeline — how does the CPU still keep exceptions precise?
It attaches the interrupt to an instruction boundary: it lets instructions up to some chosen commit point retire, squashes the rest, then takes the interrupt precisely as if it occurred between two committed instructions.
Edge case: An instruction both reads and writes the same register (e.g. R1 ← R1 + R3) — does the read see the new value?
No. Semantically the read of
R1 happens on the old architectural state; the write produces the new value only for later instructions, never for its own read.Edge case: A BEQ with a taken branch faults on the very next fetched instruction — which instruction is the fault attributed to?
The fetched target instruction that actually faulted, not the branch; the branch committed cleanly, so precise state includes its PC update, and the EPC points at the faulting target.
Recall One-line self-test
The single fact that determines return-PC for any exception is... ::: whether it is a fault (return to the same instruction) or a trap (return to the next).
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