4.1.7 Interrupts and Interrupt Service Routines
A processor cannot predict exactly when every external event will occur. A key press, completed data transfer, timer event or hardware problem may need attention while another program is running. An interrupt allows the processor to respond without permanently abandoning its current work.
By the end of this section, you should be able to:
- Explain the purpose of interrupts and why they are useful.
- Distinguish an interrupt request from the moment it is detected by the CPU.
- Identify possible causes and applications of interrupts.
- Explain why interrupts may need priorities.
- Describe how the processor saves its current state.
- Explain the role of an Interrupt Service Routine (ISR).
- Describe how normal execution resumes after interrupt handling.
Why Interrupts Are Used
Without interrupts, a processor might have to keep checking every device repeatedly to discover whether anything needs attention. This repeated checking is called polling. Polling can waste processor time when events are infrequent.
An interrupt-based system lets the main program continue until a component or software condition raises an interrupt request. The processor can then respond at a controlled point, handle the event and return to the interrupted program.
| Approach | How the processor finds out about an event | Possible consequence |
|---|---|---|
| Polling | The running software repeatedly checks a status value. | Processor time may be used even when no event has occurred. |
| Interrupt | A request is raised when attention is needed. | The processor can continue other work until the request is considered. |
Possible Causes and Applications
Interrupts can originate from hardware or software-related conditions. Their application is to make the processor respond to events that do not fit neatly into the normal sequential instruction stream.
| Cause | Original example | Why an interrupt is useful |
|---|---|---|
| User interaction | A learner presses a key while an editor is formatting a document. | The system can process the input promptly without the editor constantly checking the keyboard. |
| I/O completion or readiness | A storage controller finishes transferring a block of data. | The CPU is told that the result is ready and can continue the next part of the task. |
| Timer event | A scheduler's time slice expires after a fixed interval. | The operating system can share processor time among several processes. |
| Hardware fault | A cooling sensor reports that a processor temperature limit has been exceeded. | Protective action can be taken before normal work continues. |
| Program exception | A calculation attempts an invalid operation. | System software can report or manage the exceptional condition. |
When Is an Interrupt Detected?
An interrupt request may be raised while an instruction is being fetched, decoded or executed. In the simplified processor model used for this course, the CPU checks for pending interrupts after the current instruction has completed, at the boundary before the next normal fetch.
Waiting until an instruction boundary avoids leaving a partly completed instruction in an uncertain state. If no accepted interrupt is pending, the next fetch begins normally.
Interrupt Priority and Identification
More than one interrupt may be pending. The processor needs to identify the source so that it can run the correct service routine. It may also need to decide which request should be handled first.
| Example request | Illustrative priority | Reason |
|---|---|---|
| Critical cooling failure | High | Delay could damage hardware or make the system unsafe. |
| Storage transfer completed | Medium | The waiting program needs the completed data but a short delay may be acceptable. |
| Routine timer update | Lower | It should be handled, but a critical fault may take precedence. |
Exact priority schemes vary among processor and operating-system designs. At A-Level, the important principle is that the processor can distinguish interrupt types and handle a more urgent request before a less urgent one.
The Interrupt-Handling Sequence
The exact implementation differs among systems, but the following sequence describes the required general process.
| Stage | Processor action | Purpose |
|---|---|---|
| 1 | Complete the current instruction and check for pending interrupts. | Reach a defined state before changing program flow. |
| 2 | Identify and select the interrupt to handle. | Choose the correct response and respect priority. |
| 3 | Save the current program's processor state. | Make it possible to resume later without losing progress. |
| 4 | Load the start address of the appropriate ISR into the PC. | Redirect instruction fetching to the handler. |
| 5 | Execute the ISR and deal with the source of the interrupt. | Perform the required service or protective action. |
| 6 | Check whether another accepted interrupt must be handled. | Avoid resuming when a more urgent request is still pending. |
| 7 | Restore the saved processor state and continue the interrupted program. | Resume from the correct place with the same working values. |
Why the Processor State Must Be Saved
The running program depends on values held in registers. The PC identifies where execution should continue, while the ACC, Status Register and other registers may contain intermediate results. The ISR may change those same registers.
Before transferring control to the ISR, the processor stores the required register values in a protected area of memory. This saved collection of values is often described as the program's context or processor state.
The Interrupt Service Routine
Once the current state has been saved, the PC is loaded with the start address of the relevant ISR. The next instruction fetch therefore comes from the ISR rather than the interrupted program.
The ISR performs a focused task. For example, it may read input from a controller, record that an I/O transfer has completed, update a timer value, clear the interrupt request or initiate a safe shutdown after a serious fault.
| Interrupt source | Possible ISR action |
|---|---|
| Keyboard controller | Read the input code and place it in an input buffer. |
| Storage controller | Record that a requested block transfer has completed. |
| Timer | Update scheduling information and decide which process should run next. |
| Temperature alarm | Reduce activity, notify system software or begin a safe shutdown procedure. |
Returning to the Interrupted Program
When interrupt servicing is complete and no higher-priority request must be handled first, the processor restores the saved context. The PC regains the address of the next instruction in the interrupted program, and the other saved registers return to their previous values.
Normal fetching then resumes. From the program's perspective, execution continues from the correct point rather than restarting from the beginning.
Interactive: Interrupt and ISR Simulator
Select an interrupt source and step through the response. The simulator shows when the request is detected, which register values are saved, where the ISR begins and how the interrupted program resumes.
Common Mistakes and Misconceptions
- An interrupt request may occur during a cycle, but it is checked at the defined cycle boundary in this model.
- An interrupt does not automatically mean a hardware failure.
- The ISR is a program; it is not the electrical or logical request itself.
- The processor saves register contents so the interrupted program can resume correctly.
- Loading the ISR address into the PC does not destroy the return address because the old state has already been saved.
- The interrupted program normally resumes; it does not necessarily restart.
- Interrupt priority determines order of attention, not how long an ISR must be.
Exam Tips
For a complete interrupt-handling answer
- Finish the current instruction and check for a pending request.
- Identify or prioritise the interrupt.
- Save the PC and other required register contents.
- Load the ISR start address into the PC.
- Execute the ISR and deal with the interrupt source.
- Restore the saved state and resume the original program.
Practice
Core questions
- Define an interrupt and state one reason interrupts are useful.
- Give one hardware-related and one software-related cause of an interrupt.
- Explain the difference between an interrupt request and an ISR.
- State when interrupts are checked in the simplified fetch–decode–execute model.
- Explain why the PC and other register contents are saved.
- Describe how the processor begins executing the appropriate ISR.
- Explain how interrupt priority can affect the order in which requests are handled.
- Describe how the interrupted program resumes.
Original scenario
A media workstation is exporting a video when a storage controller reports that a requested file block is ready. Describe the interrupt-handling process from the end of the current instruction until video export resumes.
Reasoning challenge
A timer interrupt and a critical cooling interrupt are both pending. Explain why the processor may service the cooling interrupt first, and what should happen to the timer request.
Review
| Concept | Essential idea |
|---|---|
| Interrupt | A request or condition asking the processor to handle an event. |
| Application | Respond to I/O, user events, timers, faults or exceptions without constant polling. |
| Detection point | At the end of the current instruction cycle in the simplified model. |
| Priority | Determines which pending request is handled first. |
| Saved state | Register contents preserved so the interrupted program can continue correctly. |
| ISR | A program that performs the actions required for a particular interrupt. |
| Return | The saved state is restored and normal program execution resumes. |