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) Name of the routine. A routine executed in response to an interrupt is called an Interrupt Service Routine (ISR) (also "interrupt handler") — a piece of code, vectored to by hardware or firmware, dedicated to servicing one specific interrupt source.

B) Advantages of interrupt-driven I/O. Compared with software polling, interrupts let the CPU run its normal program and be asynchronously notified only when a device genuinely needs service, instead of repeatedly checking 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 polling loop provides naturally.

C) Requirements of interrupt processing. A correct interrupt-processing scheme must, in order: (i) recognize the pending request and finish (or, for a genuinely urgent case, abort) the current instruction; (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 interrupted before it can save further context (unless it deliberately re-enables interrupts for nesting); (iv) vector to the correct Interrupt Service Routine, via a fixed address, a vector table, or a device-supplied vector; (v) have the ISR service the device — read/write the data that caused the request and clear 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) Enabling other interrupts during an ISR. On entry, the controller normally masks interrupts at the current ISR's priority level (and, on many architectures, ALL maskable interrupts) so the context-save cannot itself be interrupted mid-way. To allow OTHER (typically higher-priority) interrupts to be serviced while this ISR is still running, the ISR must explicitly re-enable interrupts — execute a "set interrupt-enable" / "clear the interrupt-mask bit" instruction, usually right after it has finished saving its own context and (on a priority-controller system) after raising the in-service priority level, so that only strictly-higher-priority requests can preempt it. This is what makes nested interrupt handling possible; without that explicit re-enable, the CPU stays masked and no interrupt (of any priority) can preempt the running ISR.

E) Promoting a maskable interrupt to highest priority. A maskable interrupt is promoted to the highest priority AMONG maskable sources when its associated event, though not so catastrophic as to need a hardware non-maskable interrupt, is still time-critical enough that it must never wait behind other pending, lower-urgency maskable requests — e.g. a watchdog/timeout warning, a real-time control-loop deadline, or a data-buffer-about-to-overflow condition, where a missed or late response causes data loss or a system fault. Priority promotion guarantees that when several maskable requests are pending simultaneously, this one is always serviced first (and can preempt a lower-priority ISR already running), while the source remains software-maskable for situations (e.g. a protected critical section) where even it must be temporarily suppressed — a flexibility a true non-maskable interrupt does not offer.