Question 6 of 6: Interrupt Processing

Question 6: Interrupt Processing (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

A) Why interrupts are useful. Without interrupts, a CPU can only find out that a device needs service by polling — repeatedly reading the device's status register in a software loop, whether or not the device actually has anything ready. Interrupts let the CPU instead run its main program undisturbed and be asynchronously notified only at the instant a device genuinely needs attention, via a hardware signal that forces a call to a dedicated service routine. This is useful because it eliminates wasted polling cycles (CPU time goes to real work instead of idle status checks), gives much better, more predictable response latency to time-critical devices, and lets one CPU service many I/O devices of wildly different speeds (a keystroke every few hundred milliseconds, a disk transfer every microsecond) without wasting cycles on the slow ones or starving the fast ones. In short, interrupts are the mechanism that makes efficient, responsive multi-device I/O possible on a single processor.

B) Why interrupts should be prioritized. Real systems have multiple interrupt sources that can become active at overlapping times, and they are not equally urgent: a power-failure or memory-parity-error interrupt demands immediate action to save state before data is lost, while a keyboard keystroke can safely wait a few milliseconds. Prioritization is needed so that, when two or more interrupts arrive together (or a new one arrives while an older, less urgent one is still being serviced), the CPU services the most time-critical request first and can even preempt a lower-priority service routine already in progress. Without a priority scheme, interrupts would be serviced in an arbitrary or fixed order regardless of urgency, so a critical event could sit queued behind trivial ones long enough to cause real damage (data loss, a missed real-time deadline, or hardware damage in the power-failure case).

C) How to handle interrupts. The standard interrupt-handling sequence is: (1) the device asserts an interrupt-request line; (2) the CPU finishes its current instruction and checks the interrupt-enable state; (3) if permitted, the CPU saves the minimum processor state needed to resume later — at least the program counter, and typically the flags/status register and any registers the ISR will clobber (some architectures push these automatically, others require the ISR itself to do it); (4) the CPU disables further interrupts of equal or lower priority (or all interrupts, on a simple controller) so the handler is not itself interrupted inconsistently; (5) it vectors to the Interrupt Service Routine (ISR) associated with that source, via a fixed address, a vector table, or a device-supplied vector; (6) the ISR services the device (transfers data, clears the device's request flag, etc.); (7) the ISR restores the saved state and executes a return-from-interrupt instruction, which re-enables interrupts (if they were disabled) and resumes the interrupted program exactly where it left off.

D) Maskable vs. nonmaskable interrupts. A maskable interrupt (INTR-type) can be selectively enabled or disabled by software, by setting or clearing an interrupt-enable flag (or an individual mask bit for that source) — the CPU is allowed to ignore it during a critical section of code, such as while modifying a data structure that must not be interrupted mid-update. A non-maskable interrupt (NMI) cannot be disabled by software at all — it always takes effect regardless of the current interrupt-enable state, and is reserved for events so severe that ignoring them would be worse than interrupting anything in progress (e.g., imminent power failure, an uncorrectable memory-parity error, or a watchdog timeout). The practical rule of thumb: routine, recoverable I/O events are maskable so ordinary code can protect its critical sections; catastrophic, unrecoverable-if-ignored events are non-maskable so the system can never be left unable to respond to them.