AQA A-Level Computer Science (7517)

## Learning Outcomes

- Define an **interrupt** and explain why computers use interrupts during processing
- Describe the sequence of interrupt handling in the fetch-decode-execute cycle
- Explain the roles of the **program counter**, **stack**, registers and the **interrupt service routine**
- Distinguish clearly between interrupts and polling
- Apply interrupt knowledge to exam-style hardware and software examples
- Avoid common errors, such as saying the program restarts instead of resumes

## AQA A-Level Computer Science (7517) Syllabus

For the AQA A-Level Computer Science (7517), you are expected to understand interrupts within computer organisation and architecture, with a focus on the following syllabus points:

- Know that an interrupt is a signal from hardware or software requesting processor attention
- Understand that the CPU normally completes the current instruction before servicing an interrupt
- Explain how the current processor state is saved, commonly using the stack
- Identify the role of the **program counter (PC)** in returning to the correct place after the interrupt
- Understand the purpose of an **interrupt service routine (ISR)** or interrupt handler
- Explain how execution resumes after the interrupt has been serviced
- Compare interrupt-driven processing with polling in terms of CPU efficiency
- Recognise examples of interrupt sources such as keyboard input, timer signals and I/O completion

## Test Your Knowledge

_Attempt these questions before reading this article. If you find some difficult or cannot remember the answers, look more closely at that area during your revision._

1. What is an interrupt, and why does the CPU need interrupts?
2. Why does the CPU usually finish the current instruction before handling an interrupt?
3. What is saved on the stack during interrupt handling?
4. What does an interrupt service routine do?
5. How is interrupt-driven processing different from polling?

## Introduction

A processor normally works through instructions one after another using the fetch-decode-execute cycle. That sequential approach is efficient when nothing unusual happens. Real computer systems, though, are full of events that need attention at unpredictable times: a key is pressed, a disk finishes reading data, a printer reports an error, or a timer signal tells the operating system to switch tasks.

Interrupts exist so the CPU can respond to those events without wasting time constantly checking every device. This makes interrupts a core part of computer architecture, and exam questions often test both the sequence of handling an interrupt and the reason interrupts are more efficient than simple polling.

> **Key Term: interrupt**
> A signal from hardware or software that causes the CPU to temporarily suspend normal execution so it can deal with an event that needs attention.

## Introduction to interrupt handling

An interrupt does not mean the processor randomly abandons what it is doing in the middle of an instruction. In exam answers, the safest wording is that the CPU usually **completes the current instruction**, then checks for interrupts and services one if needed. This matters because leaving an instruction half-finished could leave registers or memory in an inconsistent state.

In simplified exam models, the CPU checks for interrupts between instructions, often described as happening at the end of the execute stage and before the next fetch begins. That means interrupt handling is added as an extra decision point in the normal cycle.

A useful way to think about this is:

- normal processing continues instruction by instruction
- after an instruction finishes, the CPU checks whether an interrupt has occurred
- if no interrupt exists, the next instruction is fetched
- if an interrupt exists, the CPU saves its current state and branches to code that handles the interrupt

This is why interrupts fit naturally into the fetch-decode-execute model rather than replacing it.

> **Key Term: fetch-decode-execute cycle**
> The repeated process by which the CPU fetches an instruction from memory, decodes it and executes it.
>
> **Key Term: context**
> The current state of the processor, including the information needed so execution can resume correctly later.

The word **context** is important. If the CPU is interrupted, it must later continue as if nothing has gone wrong. To do that, it must preserve enough information about what it was doing. This usually includes the address of the next instruction and often register contents too.

A common exam mistake is to say that the CPU saves "the current instruction" on the stack. That is too vague and often inaccurate. What really matters is the **state** needed to continue, especially the next instruction address from the **program counter** and any register values that would otherwise be lost.

> **Key Term: program counter (PC)**
> A register that stores the address of the next instruction to be fetched.
>
> **Test Tip:** In a 3- or 4-mark answer, use a clear sequence: interrupt occurs -> current instruction finishes -> state saved -> ISR runs -> state restored -> program resumes. That order usually earns marks better than a general description.

### What happens when an interrupt occurs

The handling process can be explained as a fixed sequence. Examiners like answers that give the steps in order, because interrupt handling is really about correct control flow.

A standard sequence is:

1. A device, timer, or program generates an interrupt.
2. The CPU completes the instruction it is currently executing.
3. The CPU saves the current state, usually including the **PC** and register values.
4. These values are commonly pushed onto the **stack**.
5. The CPU identifies the correct interrupt handler or ISR.
6. The ISR executes and deals with the event.
7. The saved state is restored from the stack.
8. The CPU resumes the interrupted program from the saved address.

This sequence explains two separate ideas that students sometimes mix up:

- **the interrupt signal** is the request for attention
- **the ISR** is the code that handles that request

The signal is not the same as the response. If a keyboard sends an interrupt because a key was pressed, that signal simply alerts the CPU. The ISR then reads the input and updates the system appropriately.

> **Key Term: interrupt service routine (ISR)**
> A routine that handles a specific interrupt and carries out the actions needed to deal with that event.
>
> **Key Term: stack**
> A LIFO data structure used to store items such as return addresses and register values so they can be restored in reverse order.

The stack is especially suitable here because the most recently saved values must be restored first. If the CPU pushes register values and the return address onto the stack, it can later pop them back in the correct reverse order.

Why does this matter? Because if the state is not restored properly, the original program may continue with the wrong register values or return to the wrong memory address. That could cause crashes, corrupted data, or incorrect results.

Consider this simple example. A word processor is running, and the user presses a key:

- the keyboard generates an interrupt
- the CPU finishes its current instruction in the word processor
- the CPU saves the current state
- the keyboard ISR runs and reads the key press
- the state is restored
- the word processor continues, now with the new character available for processing

The word processor does not restart. It resumes from where it was interrupted. That distinction is often tested.

### The role of the stack, registers and the PC

To answer top-band questions, you need to explain not just what happens, but why those components are needed.

The **program counter** is central because it tells the CPU where to continue. During normal processing, the PC is updated to point to the next instruction. If an interrupt occurs and the PC is not saved, the CPU has no reliable way to return to the interrupted program.

Registers matter because many instructions depend on values already loaded into the CPU. Suppose a program has partly prepared data for an arithmetic operation. If an interrupt handler uses some of the same registers and those values are not preserved, the interrupted program may resume with damaged data.

That is why exam-safe wording is usually:

- save the contents of relevant registers
- save the address of the next instruction
- restore them after the ISR completes

Worked-through example:

A CPU is processing a payroll program.

- The PC currently holds the address of the next payroll instruction.
- A disk controller sends an interrupt because a read operation has completed.
- The CPU finishes its current payroll instruction.
- The PC and register contents are pushed onto the stack.
- The disk ISR runs, handling the completed I/O request.
- The saved PC and registers are restored.
- The payroll program continues from the next correct instruction.

If the CPU did not save the PC, it might jump back to the wrong place. If it did not save registers, a salary calculation could continue with altered values. So the stack is not just a storage detail; it protects correctness.

> **Key Term: register**
> A small, fast storage location inside the processor used to hold data, addresses or control information during processing.

Some textbook treatments mention an **interrupt register** that stores details of incoming interrupts. That can help explain how the CPU knows an interrupt exists. However, in most exam answers, the higher-value marks come from describing the service sequence accurately rather than naming extra hardware unless the question specifically asks for it.

### Interrupts, polling and efficiency

A common exam angle is to compare interrupts with polling. This is not just a definition task. You should be ready to explain why one method is usually more efficient.

**Polling** means the CPU repeatedly checks whether a device needs attention. For example, it may keep asking a keyboard controller, "Has a key been pressed yet?" If the answer is no most of the time, many CPU cycles are wasted on checks that achieve nothing.

With interrupts, the CPU does not keep checking. The device signals the CPU only when attention is required.

> **Key Term: polling**
> A method where the CPU repeatedly checks a device or status flag to see whether service is needed.

Comparison:

- **Polling**
  - CPU actively checks device status again and again
  - simple to understand
  - can waste processor time
  - may delay response until the next poll

- **Interrupts**
  - device or event alerts the CPU when needed
  - better CPU efficiency for unpredictable events
  - requires interrupt handling logic and context saving
  - usually preferred for devices such as keyboards or disks

Why are interrupts usually better for I/O? Because I/O devices are often much slower than the CPU. A disk operation may take many processor cycles. If the CPU polls constantly while waiting, it spends large amounts of time doing nothing useful. If the disk instead sends an interrupt when finished, the CPU can perform other processing meanwhile.

Worked example:

Imagine a CPU needs data from a disk.

Using polling:

- CPU starts the disk read
- CPU repeatedly checks whether the read has finished
- for many cycles, the answer is "no"
- useful CPU time is lost

Using interrupts:

- CPU starts the disk read
- CPU continues with other instructions
- disk sends an interrupt when the read finishes
- CPU handles the interrupt and continues

The second approach makes better use of processor time.

This does not mean polling is always useless. If a system must check something extremely frequently and predictably, polling can be simple and acceptable. But for AQA exam answers, the safest general statement is that interrupts are **usually more efficient** because the CPU only responds when signalled.

> **Test Tip:** If a question asks for the advantage of interrupts over polling, do not just write "interrupts are faster". A better answer is: "interrupts are more CPU-efficient because the processor does not waste time repeatedly checking devices that do not need attention."

### Sources of interrupts and extended ideas

You should know realistic examples of interrupt sources, because questions often ask for one or two examples.

Common examples include:

- keyboard input
- mouse click
- disk I/O completion
- printer needing more data
- printer error such as out of paper
- timer signal
- power issue detected by the system
- program error such as division by zero

These examples help show that interrupts can come from both hardware and software contexts. A keyboard press is external hardware input. A divide-by-zero condition is generated during program execution. In both cases, the interrupt exists because the CPU must react to something outside the normal next instruction flow.

Some textbooks also discuss **priority levels**. This means some interrupts are treated as more urgent than others. A power failure warning should usually be serviced before a printer asking for more data. That makes practical sense: one event risks system failure, while the other is less urgent.

You may also meet the terms **interrupt vector** and **interrupt vector table**.

> **Key Term: interrupt vector**
> The memory address of the ISR for a particular interrupt type.
>
> **Key Term: interrupt vector table**
> A table containing the addresses of ISRs for different interrupt types.

These terms explain how the CPU finds the correct ISR quickly. Instead of searching memory, the CPU uses the interrupt type to locate the relevant address in the interrupt vector table, then jumps to that ISR.

This is useful background and may appear in some teaching materials. Still, if the question only asks for the role of interrupts, do not let extension detail replace the core sequence of save state, run ISR, restore state, resume.

Common student errors:

- saying the CPU stops immediately mid-instruction
- saying the original program restarts from the beginning
- forgetting to mention the saving of the PC or registers
- confusing the interrupt signal with the ISR
- writing about the operating system in general without explaining what the CPU actually does

A strong answer stays close to the processor sequence.

## Key Point Checklist

_This article has covered the following key knowledge points:_

- An interrupt is a signal from hardware or software requesting CPU attention
- The CPU normally completes the current instruction before servicing an interrupt
- Interrupts are checked between instructions in simplified fetch-decode-execute models
- The current processor state, or context, must be saved before the interrupt is handled
- The **program counter** is saved so the CPU knows where to resume execution
- Register contents are often saved as part of the context
- The **stack** is commonly used to store saved state during interrupt handling
- An **interrupt service routine (ISR)** is the code that handles the interrupting event
- After the ISR finishes, the saved state is restored and the original program resumes
- Interrupt-driven processing is usually more efficient than polling because the CPU does not repeatedly check devices unnecessarily
- Common interrupt sources include keyboard input, timer signals, I/O completion and program errors
- An **interrupt vector** is the address of an ISR, while an **interrupt vector table** stores multiple ISR addresses

## Key Terms and Concepts

- interrupt
- fetch-decode-execute cycle
- context
- program counter (PC)
- interrupt service routine (ISR)
- stack
- register
- polling
- interrupt vector
- interrupt vector table


Computer Organisation and Architecture - Interrupts