amazon.co.ukExam-focused AQA 7517, OCR H446 and WJEC/Eduqas revision for computer systems and architecture: CPU components, registers, fetch-decode-execute, pipelining, memory hierarchy, virtual memory, OS functions and Amdahl's law with worked register transfers.
The standard 6-marker here is 'describe the role of the following registers...' (AQA 4.4.1, OCR 1.1.1, WJEC 1.4). Learn this table exactly — the purposes below are the mark-scheme wording:
| Register | Purpose |
|---|---|
| Program counter (PC) | Holds the address of the next instruction to be fetched |
| Current instruction register (CIR) | Holds the instruction currently being decoded/executed |
| Memory address register (MAR) | Holds the address of the memory location about to be read/written |
| Memory data register (MDR) | Holds the data just read from, or about to be written to, that address |
| Accumulator (ACC) | Holds the result of ALU operations |
| Status register (SR) | Holds flags (carry, negative, overflow, zero) set by the ALU and tested by branches |
The classic trap: PC holds the address of the next instruction (not the current one), and MAR holds an address while MDR holds the data at that address. Pairs go together in traces: MAR/MDR for memory access, PC/CIR for instruction flow.
The other components: the ALU performs arithmetic (add, subtract) and logic (AND, OR, shifts), and sets the status flags; the control unit decodes the opcode in the CIR and generates the control signals that sequence every other component; the clock synchronises them; general-purpose registers hold intermediate values (RISC designs have many, CISC few).
Buses carry everything between them. Three buses, three examinable facts: the address bus is unidirectional (CPU to memory) and its width determines the addressable memory — 32 address lines address 2^32 bytes = 4 GiB; the data bus is bidirectional and its width determines how much data moves per transfer — 64 lines move 8 bytes at a time; the control bus carries command and timing signals (read, write, clock, interrupt request). Exam question pattern: 'Explain how the width of the address bus affects performance.' Answer: each additional line doubles the addressable space (2^w), not the speed directly — but more addressable memory allows more RAM and less swapping, which improves performance indirectly. State that distinction and you separate yourself from candidates who say 'wider bus = faster'.
The FDE cycle (OCR 1.1.1, AQA 4.4.1) repeats for every instruction. Learn the register transfers in order — this exact sequence is the mark scheme:
1. FETCH MAR <- [PC] // address of next instruction to MAR PC <- [PC] + 1 // PC incremented ready for the next fetch MDR <- [[MAR]] // instruction at that address read into MDR CIR <- [MDR] // instruction copied to CIR 2. DECODE // CU splits CIR into opcode and operand // CU generates the control signals for the opcode 3. EXECUTE // ALU performs arithmetic/logic, or data is loaded/stored // status flags updated; result left in ACC or destination
Double-bracket notation: MAR <- [PC] copies the contents of PC into MAR; MDR <- [[MAR]] copies the contents of the memory location whose address is in MAR — the nested brackets mean 'dereference the address'. Exam trap: PC is incremented during fetch, before decode, so it already points at the next instruction while the current one executes; branch instructions then overwrite PC during execute, which is how jumps work.
Worked micro-trace for ADD #5 (immediate operand 5): fetch — MAR gets PC, PC increments, CIR gets ADD #5; decode — CU recognises an immediate add; execute — ACC <- ACC + 5, flags updated. For LOAD 200 (direct addressing): fetch as above; decode; execute — MAR <- 200, MDR <- [[MAR]], ACC <- [MDR]. Note the operand flows through MAR/MDR in execute — a second memory access after the fetch — which is exactly the detail that separates full marks from half marks on 'describe the execute stage'.
Pipelining overlaps the three stages: while one instruction executes, the next is decoded and a third fetched — so an ideal pipeline completes about one instruction per cycle instead of three cycles per instruction. Hazards break the flow, and exams ask you to name and exemplify all three:
ADD R1, R2, R3 followed immediately by ADD R4, R1, R5 — R1 is not ready. Fixed by stalling (pipeline bubbles) or forwarding the result directly between stages.Exam question pattern: 'Explain what a data hazard is and how a pipelined processor deals with it.' Full-credit: define the dependency (consecutive instructions, second needs the first's result before it is written back), give the two-instruction example, then state stall-and-forward as the fix.
Memory is arranged by the trade-off speed versus cost versus size — fastest and smallest at the top:
| Level | Typical access time | Typical size |
|---|---|---|
| Registers | < 1 ns | bytes (tens of registers) |
| L1 cache | ~1 ns | tens of KiB |
| L2/L3 cache | ~4–20 ns | hundreds of KiB – tens of MiB |
| RAM (main memory) | ~100 ns | GiB |
| SSD | ~100 microseconds | hundreds of GiB |
| HDD | ~10 ms | Terabytes |
Cache holds copies of recently and frequently used data. On a hit, the CPU reads from cache — no wait. On a miss, the data is fetched from RAM (a stall of ~100 cycles) and cached for reuse. Why cache improves performance: programs exhibit locality of reference — temporal locality (recently used data is used again: loop counters, accumulators) and spatial locality (nearby addresses are used together: sequential instructions, array traversal) — so a small cache captures a large fraction of accesses. Quote both locality terms; they are the explanation marks. Cache policies worth one line each: cache replacement replaces the least recently used line; write policies decide when cached writes reach RAM (write-through immediately, write-back lazily with a dirty bit).
Virtual memory extends RAM using secondary storage: memory is divided into fixed-size pages; a page table maps virtual addresses to physical frames; pages not currently in RAM live on disk. When a process accesses a page that is not in RAM — a page fault — the OS suspends the process, loads the page from disk, updates the page table and resumes. If pages are replaced too aggressively (RAM too small for the working set), the system thrashes: constantly swapping pages in and out and doing almost no useful work — the classic evaluation point. Exam question pattern: 'Explain how virtual memory allows a program larger than physical RAM to run, and why excessive reliance on it degrades performance.' Answer: pages of the program are swapped between RAM and disk via the page table on demand (page faults), so the program's full address space need not be resident; disk access is orders of magnitude slower than RAM, so heavy swapping (thrashing) dominates execution time.
Also know why the OS needs memory management at all: multiple programs run concurrently, so memory must be partitioned and protected — one process must not read or write another's memory; paging provides that isolation via the page table (each process has its own mapping), which is the link between the hardware and the OS section below.
The OS is the layer between hardware and applications, and its examinable functions fall into four groups (OCR 1.2.1, WJEC 1.5, AQA 4.4.4).
Memory management: allocates and deallocates memory to processes; implements paging (fixed-size pages, any page fits any frame — no external fragmentation, small internal fragmentation in the last page) and segmentation (variable-sized logical units such as code, stack, heap — matches program structure but suffers external fragmentation); manages the page table and virtual memory; enforces protection between processes. The paging-vs-segmentation comparison is the standard question: paging divides memory into fixed-size blocks chosen for hardware convenience; segmentation divides into variable-size logical units chosen for the program's structure; both need the OS to translate addresses, and both enable sharing and protection.
Scheduling decides which ready process gets the CPU next. Know the algorithms, their fairness and their failure modes:
| Algorithm | Method | Key property |
|---|---|---|
| Round robin | Each process gets a fixed time slice, then rejoins the queue | Fair response time; slice too small = overhead, too large = poor responsiveness |
| First come, first served | Runs each process to completion in arrival order | Simple; short jobs stuck behind long ones (convoy effect) |
| Shortest job first | Runs the process with the smallest predicted duration | Best average waiting time; needs prediction; long jobs can starve |
| Shortest remaining time | Preemptive SJF — preempts if a shorter job arrives | Even better waiting time; more context switches; starvation risk |
| Multilevel feedback queues | Multiple queues with priorities; processes move between them on behaviour | Balances interactive responsiveness with throughput |
Exam pattern: 'A short interactive task arrives while a long batch job is running. Explain which scheduling algorithm gives the best response time.' Answer: round robin (or multilevel feedback) — the batch job is preempted at its time-slice boundary so the interactive task runs soon; FCFS would make it wait for the whole batch; SJF favours the short task once both are queued but cannot preempt a running job unless implemented as SRTN. Also know preemptive vs non-preemptive: preemptive schedulers can interrupt a running process (timer interrupt); non-preemptive wait for it to yield — and preemption is what makes multitasking possible.
Interrupt handling: an interrupt is a signal (I/O completion, timer tick, hardware fault, program error) that suspends the current process. The sequence to reproduce: (1) the processor finishes the current instruction; (2) it saves the current context (PC, status register, registers) on the stack; (3) it loads the interrupt service routine (ISR) address from the interrupt vector table and runs it; (4) on completion the saved context is restored and the interrupted program resumes transparently. Interrupts are what allow the CPU to multiplex between programs and to react to devices without busy-waiting — the exam point: polling wastes cycles checking devices repeatedly, whereas interrupts let the device signal the CPU only when needed.
CISC vs RISC (OCR 1.1.2) — the comparison to reproduce in full:
| Feature | CISC | RISC |
|---|---|---|
| Instructions | Many, complex, variable length | Few, simple, fixed length |
| Execution | Multiple cycles; interpreted by microcode | One cycle per instruction |
| Memory access | Many addressing modes; instructions can access memory directly | Load/store architecture — only load/store touch memory |
| Registers | Fewer | Many |
| Pipelining | Harder — variable instruction length | Designed for it — uniform stages |
| Compiler | Simpler to target; hardware does more | Must do more work; hardware simpler |
Evaluation line to add: modern x86 processors are externally CISC but internally translate to RISC-like micro-operations, so the distinction is about design philosophy, not clean categories; ARM processors (phones, Raspberry Pi) are RISC, chosen for power efficiency — one instruction per cycle and simpler decode burn less energy.
Parallel architectures: SIMD (single instruction, multiple data) applies one instruction to many data items at once — graphics pipelines and vector units; MIMD (multiple instruction, multiple data) is multiple independent cores running different instruction streams — general multicore. Also know the GPU as a co-processor: thousands of simple cores specialised for the massively parallel arithmetic of graphics and machine learning, while the CPU handles general sequential control flow; co-processors (maths, floating-point units) offload specific workloads from the main CPU.
Amdahl's law quantifies the limit of parallelism: if a fraction p of a program can be parallelised and the rest (1 − p) is serial, the speedup on n cores is:
speedup = 1 / ( (1 - p) + p / n )
Worked calculations to memorise (these are the exact exam patterns):
The conclusion to quote: beyond a few cores, returns diminish sharply and the serial fraction — not the core count — sets the maximum speedup. Exam question pattern: 'Explain why adding more cores eventually stops improving performance.' Answer: only the parallelisable fraction speeds up; the serial portion runs at the same speed regardless, so as n grows the p/n term vanishes and speedup approaches 1/(1-p), a hard ceiling set by the code's serial fraction. Add the counterpoint for evaluation: better single-core performance (clock speed, IPC, cache) helps serial code, whereas more cores only helps parallel code — which is why optimisation priorities depend on the workload.