Pause, preserve and resume: what an interrupt must protect
By UK A Level Computer Science · independent study · myAudience
Image: illustration, not a documentary photograph. This toy machine accepts an interrupt between completed instructions and saves the next instruction address, PC=104, with live register R0=7 and flag Z=false. Service can change working state, but restoration recovers the full tuple before ADD R0,3 produces 10. The lower panel restores the inner frame (904,99,true) before the outer frame (104,7,false). Protected frames describe the stipulated software context discipline, not automatic hardware saving of every register or a universal ISA saved-PC rule. The 160-pixel preview supports recognition, not reading every tuple. · Original project scientific illustration; defined teaching model, not a calibrated measurement or exam-board figure.
Pause, preserve and resume: what an interrupt must protect
An interrupt lets a processor respond to an event without requiring the running program to check every device continuously. A timer tick or an input device needing service may request attention while another program is running. A synchronous exception instead arises from execution of a particular instruction, such as an instruction-defined fault. These categories explain the relationship to the running instruction; they do not establish that every interrupt is accepted immediately. A request can remain pending while enable settings, priorities or execution rules prevent acceptance. Distinguish an event being raised, the processor accepting it and the handler completing its service.
Scope
architecture teaching lesson associated with the existing grouped requirement the related topic. No new official demand or assessment closure is established. The invented machine below accepts an interrupt between completed instructions and records the next instruction's address. That chosen rule is not the rule of every processor: the inspected RISC-V draft describes mepc holding the interrupted instruction's address. Source-specific details and toy trace assumptions must stay separate.
To resume correctly, the system must preserve the interrupted computation's relevant state. That state can include where execution should resume, live working registers and status flags used by later decisions. An instruction's result may already be in a register while the next instruction has not yet consumed it. If a handler overwrites that register and returns without restoring it, the old program continues with a new value it never calculated. Saving only the program counter does not repair that loss. Conversely, saving every imaginable byte on every interrupt is not an explanation of which state this particular execution actually requires.
Our teaching machine completes one instruction at a time and accepts an interrupt only at a boundary before the next instruction starts. At one such boundary, its next program counter is 104, R0 holds 7 and the zero flag Z is false. The next instruction at address 104 adds 3 to R0, then recomputes Z. The handler must preserve the tuple (PC=104, R0=7, Z=false) before reusing any of those values. The numeral 104 is a fictional address, not a time, line number or real machine-code encoding. This boundary convention makes the trace checkable; it must not silently be transferred to an ISA with a different saved-PC meaning.
A handler has two kinds of work: service the event and protect the computation it displaced. It can use a separate saved context to retain the tuple, perform its own operations, restore the saved values, then use the machine's specified return mechanism. A handler that writes R0=99 for its own calculation must restore R0=7 before the interrupted program uses R0. Likewise, a comparison inside the handler can change Z; restoring the original flag prevents an old conditional branch from observing the handler's comparison instead of its own. Returning to the correct address with incorrect data or flags is still an incorrect return.
Hardware and software responsibilities depend on the architecture and execution environment. Some control information is recorded automatically on trap entry; a handler or its entry routine can still need to save the general-purpose registers it will clobber. The inspected official RISC-V source illustrates separate exception-PC and privilege/interrupt-enable state, with a trap-return instruction restoring control. It does not justify saying that hardware automatically copies all live working registers to a complete software frame. Our tuple model includes every value required by this stipulated trace; it is not a complete ABI, operating-system context switch or interrupt implementation.
Nested interrupts require more than a single scratch slot if acceptance permits an inner handler to interrupt an outer one. Suppose the outer handler saves R0=7 into one shared slot and then sets R0=99. If the inner handler overwrites that same slot with 99, the old 7 has been lost even if the inner return is correct. Distinct frames preserve the outer tuple and the inner tuple separately, with the most recently suspended context restored first. A stack is a useful model for this last-in, first-out relationship. Whether nesting is enabled, which events can pre-empt and how much stack space is available are additional policies that must be specified.
Restoring state is not the same as acknowledging the device event. An interrupt source might need a defined acknowledgement or service action so the event does not simply trigger again. Different devices have different rules; there is no universal “write zero to clear every interrupt” instruction. Conversely, a handler that restores registers perfectly but never performs the required service has not completed the task. Keep these two obligations separate in a trace: a software context records computation state, while device state records the event being handled. A real design also needs bounds for handler duration, repeated events and resource use.
Image: illustration, not a documentary photograph. This toy machine accepts an interrupt between completed instructions and saves the next instruction address, PC=104, with live register R0=7 and flag Z=false. Service can change working state, but restoration recovers the full tuple before ADD R0,3 produces 10. The lower panel restores the inner frame (904,99,true) before the outer frame (104,7,false). Protected frames describe the stipulated software context discipline, not automatic hardware saving of every register or a universal ISA saved-PC rule. The 160-pixel preview supports recognition, not reading every tuple.
Test an interrupt explanation by asking which values a resumed instruction would read. Trace a handler that deliberately changes each live register and flag, then confirm that restoration recovers the expected result. Trace nesting only after stating an acceptance policy and saved-frame order. The source-defined PC convention must be checked rather than guessed, particularly when comparing interrupts and exceptions. This lesson develops a bounded save/service/restore/return argument. It is not privileged-code advice, a production handler, a complete architecture course or a demonstration of assessed mastery. The saved tuples are synthetic and contain no reader information.
Source boundaries and open work
Actual architecture the related topic supplies the formal grouped scope: interrupt service and preservation of the volatile environment. Existing canonical requirement the related topic is unbound in the pinned24-lesson owner. Actual RISC-V official project machine.adoc main body was retrieved on 6 October 2026 and pinned privately: mstatus privilege/enable-stack passage lines350–415, mepc_op at1708–1711 and xret_op around2664 establish the specific control-state example. That moving main-branch source is illustrative draft evidence, not a claimed ratified release or a chosen hardware configuration. Its interrupted-instruction-PC rule is deliberately not substituted for the toy next-PC rule. General register-saving and ABI details require a selected implementation before executable publication. URLs:; https://raw.githubusercontent.com/riscv/riscv-isa-manual/main/src/priv/machine.adoc. The reviewed illustration is schematic; its full caption explains the toy model and why small previews support recognition rather than detailed reading. Full qualification coverage remains open.
Worked example: Question: At the stipulated interrupt boundary, PC=104, R0=7 and Z=false. The instruction at address 104 is ADD R0,3; the instruction following it is at address 108. ADD recomputes Z to true exactly when its result is zero. During service, the handler writes R0=99, sets Z=true and uses its own instruction addresses. Show the saved tuple, the correct restoration and the resumed result. Then show the result if the return address is restored but R0 is not. Explain why restoring flags still matters even though ADD recomputes Z in this particular trace.
Before the handler changes live state, save (PC=104, R0=7, Z=false) in a distinct context frame. After the required event service, restore all three values and return under the toy next-PC rule. The resumed instruction is ADD at 104; it calculates 7+3=10, leaves R0=10 and sets Z=false because 10 is nonzero. The next instruction address becomes 108 under the stipulated instruction layout. The handler's R0=99 and Z=true have not become inputs to the resumed program.
If only PC is restored and R0 remains 99, ADD calculates 99+3=102, not 10. ADD would set Z=false here too, so observing a plausible final flag would not reveal the corrupted arithmetic input. Restoring the original Z is nevertheless part of protecting the interrupted context: an alternative next instruction could branch on Z before any new arithmetic recomputes it. A correct context-return policy should not rely on accidentally overwriting an incorrect flag before anyone notices. The trace assumes the saved frame remains intact and the event service terminates; it does not prove those properties for real hardware.
Answer: Before the handler changes live state, save (PC=104, R0=7, Z=false) in a distinct context frame.
Check your understanding: Question: An outer handler saves (PC=104, R0=7, Z=false) in one shared frame. Later its own resumable state is (PC=904, R0=99, Z=true). An inner interrupt is accepted and overwrites the shared frame with that inner suspended tuple. The inner handler services its event and restores the shared tuple correctly. What happens when the outer handler then returns using the same frame? Show how two distinct frames repair the problem, and identify a different explicit policy that would prevent this particular nesting overwrite without claiming all events can be ignored.
Answer: The inner return restores (PC=904, R0=99, Z=true), so it can resume the outer handler correctly. However, the only stored tuple is now that inner suspended state. If the outer handler uses it to return, it restores PC=904 rather than PC=104 and R0=99 rather than 7, with Z=true rather than false. It has lost the interrupted program's context. The error is not just an incorrect numerical answer to ADD: control can return to a handler address instead of the old program.
With two distinct frames, the lower frame retains (104,7,false); the top frame contains (904,99,true). The inner return restores and removes only the top frame. After the outer handler completes its service, its return restores and removes the lower frame, leaving the old program at 104 with R0=7 and Z=false. Then ADD produces 10 as before. This relies on the specified last-in, first-out frame discipline and enough storage for both frames.
Alternatively, a defined policy can disable acceptance of the relevant nestable interrupt class while the outer handler is active, retaining its request as pending for later handling. The policy must state which events are masked and how pending service resumes; it is not a promise that all fault, higher-priority or non-maskable mechanisms can be delayed. This alternative prevents the stipulated inner overwrite by changing acceptance, whereas separate frames preserve correctness when that nesting is allowed. Neither alternative supplies a universal processor implementation.
Why: The failure occurs because one storage object is used for two different suspended computations. A correct inner return can coexist with a broken outer return, so checking only the newest restoration is insufficient. Track ownership of the complete tuple, including PC and flags, then remove frames in suspension order. The alternate policy changes whether the inner interruption is accepted; it does not recover a tuple after it has already been overwritten. Keeping those mechanisms separate prevents a vague “save registers” instruction from hiding a control-flow error.