Type of Software and Interrupts

Software splits into two big families.

System software. Runs and manages the computer itself.

• Operating systems (Windows, macOS, Linux, Android, iOS) — the master.
• Device drivers — translate between the OS and specific hardware.
• Utility programs — small tools for maintenance (anti-virus, file compression, defragmenter, backup, screen-recorder, disk-cleaner).
• Firmware — low-level code in hardware (BIOS, UEFI, embedded controllers).

Application software. Does the actual things users want to do.

• Productivity (word processor, spreadsheet, presentation).
• Web browsers.
• Image / video editors.
• Games.
• Media players.

Cambridge tip. Mark scheme expects students to differentiate by PURPOSE: system runs the COMPUTER; applications do USER TASKS. A web browser is APPLICATION software even though it ships with the OS.

The operating system is the master conductor. The roles you should know:

1. Memory management. Allocates RAM to running processes, tracks free/used pages, uses virtual memory when RAM is tight, isolates processes so they can't read each other's memory.

2. Process / multitasking management. Schedules CPU time across multiple processes. Each running program is a 'process' — the OS decides which gets CPU time, when, and for how long. Lets multiple programs appear to run simultaneously.

3. File management. Provides a hierarchical file system (folders, files), reads/writes/copies/deletes files, enforces permissions, indexes for search.

4. Device / peripheral management. Talks to hardware via DEVICE DRIVERS. Spools print jobs, manages buffers, handles interrupts from peripherals.

5. Security and user management. User accounts, permissions, password handling, encryption services.

6. User interface. Provides a way for users to interact — graphical (windows, icons, mouse) or command-line (text commands).

7. Error handling. Catches problems (out-of-memory, missing file, crashed app) and either resolves them or reports them gracefully.

8. Provides a platform for applications. Applications use OS APIs (system calls) to do their work without dealing with hardware directly.

Cambridge tip. Mark scheme expects you to NAME the role and BRIEFLY describe what it does. Naming alone gets half the marks; describing alone gets you nowhere if the role isn't recognisable.

An interrupt is a signal to the CPU that something needs immediate attention. The CPU pauses what it's doing, deals with the cause, then resumes.

Sources of interrupts.

• Hardware — keypress, mouse click, packet arrived on the network, printer buffer empty, disk read complete.
• Software — division by zero, attempt to access invalid memory, system call from an application.
• Timer — periodic clock tick used for scheduling.
• Error — power failure, hardware fault.

Why have interrupts? Two alternatives are worse:

1. Polling — the CPU constantly checks whether each device has anything to say. Wastes CPU time when devices are idle.
2. Ignoring devices entirely — peripherals couldn't get the CPU's attention.

Interrupts mean the CPU only spends effort on a device when there's actually something to do.

Cambridge tip. When a question gives a scenario, name a SPECIFIC cause that fits — 'user pressed a key', 'printer buffer is empty', 'division by zero in a program' — not just 'an interrupt occurred'.

When an interrupt arrives, the CPU follows a strict procedure:

1. Finish the current FDE step. It would be chaos to abandon mid-fetch, so the CPU finishes its current micro-step.

2. Save state. The CPU saves the current register values (especially the program counter) onto a stack so it can come back later.

3. Identify the source. The CPU determines which device or condition triggered the interrupt and looks up the address of the appropriate ISR (Interrupt Service Routine) in the interrupt vector table.

4. Execute the ISR. The CPU runs the ISR code. This is the actual handling — read the keypress, refill the printer buffer, log the error.

5. Restore state. Once the ISR finishes, the CPU pulls the saved register values back off the stack.

6. Resume. The CPU continues the original program at the exact instruction it was about to execute when the interrupt arrived. The user typically doesn't notice anything happened.

Priority matters. If a high-priority interrupt arrives mid-ISR, the CPU may save state again and handle the new interrupt before returning to the previous one (nested interrupts).

Cambridge tip. Top-band candidates produce the SIX-STEP chain verbatim. Mark scheme rewards every named stage.

Buffers and interrupts solve the same underlying problem from different angles: the CPU is fast and peripherals are slow.

Buffer. A small area of memory between two devices that work at different speeds. Data is loaded into the buffer at the FAST end and drained at the SLOW end. The fast device doesn't have to wait — it can dump its data and move on.

Interrupt. Lets the slow device tell the fast one when it's ready for more data, instead of the fast one polling.

Worked example — printing a document.

1. The computer sends data to the printer's buffer.
2. The CPU is free to do other work — the printer drains the buffer at its slow pace.
3. When the buffer is nearly empty, the printer sends an INTERRUPT to the CPU.
4. The CPU's ISR for the printer fills the buffer with more data.
5. Repeat until the document is fully printed.

This pattern (buffer + interrupt) appears throughout computing — keyboards, network cards, disk controllers, audio playback all use it.

Cambridge tip. Mark scheme expects the chain explicitly: BUFFER frees the CPU; INTERRUPT signals when more data is needed. Examiner reports flag answers that mention only one half of the pairing.