Question 6 of 6: Interrupt-Driven I/O

Question 6: Interrupt-Driven I/O (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. Interrupts let the CPU run its normal program and be asynchronously notified only when a device genuinely needs service, instead of repeatedly polling every device's status register in a tight loop. This gives far better CPU utilization (useful work proceeds between real I/O events rather than being spent on idle status checks), bounded and predictable response latency to a device request, the ability to service many devices of very different speeds without wasting cycles polling the slow ones, and support for priority arbitration among simultaneous requests — none of which a simple polling loop provides naturally.

B) Why interrupts should be prioritized. Real systems have multiple interrupt sources that can become active at the same time or in overlapping windows, and different sources carry very different urgency: a power-fail or data-loss condition demands service far sooner than a keyboard keystroke. Without a priority scheme, a low-urgency interrupt could be serviced first (or a burst of low-priority requests could starve a critical one), and a nested nesting-capable design has no principled way to decide which of two simultaneous requests the CPU should service first or whether a currently-running ISR should be pre-empted. Prioritizing interrupts guarantees the most urgent/time-critical event is always serviced first (and can pre-empt a lower-priority ISR already in progress), which is essential for correctness in real-time and safety-relevant designs.

C) How to handle interrupts. A CPU handles an interrupt through a fixed sequence: (i) finish (or, for a non-maskable/urgent case, abort) the current instruction and recognize the pending request; (ii) automatically save the minimum context needed to resume — at least the program counter, typically the status/flags register too; (iii) mask same-or-lower-priority interrupts (so the handler is not itself re-interrupted before it can save further context, unless it deliberately re-enables interrupts for nesting); (iv) vector to the correct Interrupt Service Routine (ISR), via a fixed address, a vector table, or a device-supplied vector; (v) the ISR services the device — reads/writes the data that caused the request and clears the device's request flag so it does not re-fire immediately; and (vi) execute a return-from-interrupt instruction that restores the saved context and resumes the interrupted program exactly where it left off.

D) Maskable vs. nonmaskable interrupts. A maskable interrupt can be selectively disabled ("masked") by software, via an interrupt-enable bit or an interrupt-mask register — the CPU is free to ignore it while it is masked, which is how a system protects a critical section of code or gives certain lower-urgency devices lower priority than the code currently running. A nonmaskable interrupt (NMI) cannot be disabled by software at all; it is wired to always interrupt the CPU regardless of the current mask state, reserved for conditions so urgent or catastrophic (imminent power loss, a memory-parity/bus-fault error) that the system must never be able to accidentally — or deliberately — suppress the response.