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) Interrupt service routine. The routine invoked when an interrupt occurs is called an Interrupt Service Routine (ISR), also called an interrupt handler. On recognizing an active interrupt request, the CPU finishes (or aborts, for a non-maskable case) its current instruction, automatically saves the minimum context needed to resume (at least the program counter, and typically the flags/status register), and vectors to the ISR's entry address — either fixed by hardware or supplied by the interrupting device itself (vectored interrupts). The ISR services the device (reads/writes the data that caused the request, clears the request flag) and returns control with a special return-from-interrupt instruction that restores the saved context.

B) Advantages of interrupt-driven I/O over polling. Interrupts let the CPU run its normal program and be asynchronously notified only when a device genuinely needs service, instead of the CPU repeatedly polling every device's status register in a tight loop. This gives: (i) far better CPU utilization — useful work proceeds between real I/O events rather than being spent on idle status checks; (ii) bounded, predictable response latency to a device request (versus the variable delay of a polling loop's period); (iii) the ability to service many devices of very different speeds without wasting cycles polling the slow ones; and (iv) support for priority arbitration among simultaneous requests, which a simple polling loop does not naturally provide.

C) Requirements of interrupt processing. A working interrupt system needs: (i) a hardware interrupt-request line (or lines) plus an acknowledge/enable mechanism the CPU can assert; (ii) automatic saving of the machine state (at minimum the return address, usually flags too) before control transfers, so the interrupted program can resume exactly where it left off; (iii) a defined vectoring mechanism (fixed address, vector table, or device-supplied vector) that gets the CPU to the correct ISR; (iv) a priority/masking scheme to arbitrate simultaneous or nested requests (an interrupt-mask register and/or a priority encoder); and (v) a return-from-interrupt instruction that restores the saved state and resumes the interrupted program, plus a mechanism (in hardware or in the ISR itself) to clear/acknowledge the servicing device's request so the same interrupt does not re-fire immediately.

D) Enabling other interrupts during an ISR. By default, most controllers automatically disable (mask) further maskable interrupts the moment one is accepted, so the ISR is not itself re-interrupted before it has saved enough context. To allow OTHER (typically higher-priority) interrupts to be serviced while the current ISR is still running, the ISR must explicitly re-enable the interrupt system — executing an "enable interrupts" instruction (e.g. after saving its own context) — which permits nested interrupt handling: a higher-priority request can then interrupt the current ISR, while lower-or-equal priority requests remain masked until the current ISR finishes and executes return-from-interrupt (which typically re-enables interrupts and restores the previous priority level automatically).

E) Promoting a maskable interrupt to highest priority. Ordinarily, priority reflects how urgently a device needs service relative to others, and a real-time or safety-critical event can arise whose consequences of a delayed response (data loss, an out-of-range sensor reading, an imminent hardware fault) are more severe than for any other maskable source in the system — yet it is still a condition the system may need to suppress deliberately in some operating modes (unlike a true non-maskable interrupt), so it cannot simply be wired as NMI. Promoting it to the highest priority among the maskable interrupts guarantees it pre-empts every other maskable request (though it can still be masked off entirely when required), giving it the fastest possible response the maskable-interrupt scheme can offer without permanently removing the system's ability to disable it.