OCR A-Level Computer Science: Processors & Hardware — Complete Revision Guide

Processors and hardware is the foundation on which every other topic in OCR A-Level Computer Science (H446) is built. Before you can reason about operating systems, compilers, data structures or networks, you need a confident mental model of what a processor physically does: how the components of the CPU cooperate to fetch an instruction from memory, decode it, and carry it out, and how that single repeating cycle — billions of times a second — adds up to a running program. This is the topic that turns the abstract idea of "the computer" into a concrete machine you can describe, diagram and reason about under exam conditions.

In the H446 specification this material sits in module 1.1 (the characteristics of contemporary processors, input, output and storage devices) and is examined in Component 01: Computer Systems, the written paper that covers the theoretical content of the course. Questions here are reliably split between recall of component roles and the registers involved in the fetch-decode-execute cycle, and explanation items that ask you to compare architectures (Von Neumann versus Harvard, CISC versus RISC) or to justify a choice of storage medium for a given scenario. The skill the examiners reward is precise vocabulary used in the right place — naming the Memory Address Register rather than "a register", or distinguishing magnification of clock speed from genuine performance gains delivered by extra cores and pipelining.

This is Course 1 of 11 on the LearningBro OCR A-Level Computer Science learning path. The course, Processors & Hardware, opens with CPU architecture and the fetch-decode-execute cycle, develops the factors that affect processor performance, then surveys the peripheral devices — input, output and the storage hierarchy — before closing on embedded systems. Get this fluent and the rest of the path, from Software & Systems through to Programming, becomes a sequence of stories about software exploiting the machine you have just learned to describe.

Guide Overview

The Processors & Hardware course is ten lessons moving from the internal architecture of the CPU through performance factors into peripheral devices and the storage hierarchy, closing on embedded systems.

• CPU Architecture
• The Fetch-Decode-Execute Cycle
• Processor Types
• Pipelining
• Input Devices
• Output Devices
• Primary Storage
• Secondary Storage
• Storage Comparison
• Embedded Systems

CPU Architecture

The CPU architecture lesson establishes the internal components of the processor and the buses that connect it to memory. The two units every candidate must name are the Arithmetic Logic Unit (ALU), which performs arithmetic operations and logical comparisons and houses the accumulator, and the Control Unit (CU), which directs the operation of the processor by decoding instructions and sending control signals to coordinate the other components. Surrounding these are the registers: small, extremely fast storage locations inside the CPU itself.

The five special-purpose registers that recur throughout H446 are the Program Counter (PC), holding the address of the next instruction to be fetched; the Memory Address Register (MAR), holding the address currently being read from or written to; the Memory Data Register (MDR), holding the data or instruction currently being transferred to or from memory; the Current Instruction Register (CIR), holding the instruction currently being decoded and executed; and the Accumulator (ACC), holding the intermediate results of ALU operations. Learn the exact role of each — confusing the MAR and the MDR is one of the most common avoidable mark losses on this topic.

The CPU communicates with main memory over three buses. The address bus carries memory addresses from the processor to memory and is unidirectional; its width determines the maximum addressable memory (a bus of n lines can address 2^n locations). The data bus carries the actual data and instructions and is bidirectional; its width affects how much data can be moved per transfer. The control bus carries timing and command signals such as the read/write line and clock pulses. A clean diagram of the ALU, CU, registers and three buses, redrawn from memory, is the single most efficient way to lock this lesson down.

This lesson also introduces the two stored-program architectures. The Von Neumann architecture uses a single shared memory and a single bus system for both instructions and data, which is simple and cost-effective but creates the "Von Neumann bottleneck" — instructions and data cannot be fetched simultaneously over the one bus. The Harvard architecture uses separate memories and separate buses for instructions and data, allowing both to be fetched at once; it is common in embedded systems and digital signal processors, a connection picked up again in the embedded systems lesson.

The Fetch-Decode-Execute Cycle

The fetch-decode-execute cycle lesson is the conceptual heart of the whole module, and a near-guaranteed Component 01 question. The cycle is the continuous process by which a processor runs a program one instruction at a time. The register transfers should be learned as a precise sequence rather than a vague summary.

In the fetch stage, the address in the PC is copied to the MAR; the instruction at that address is fetched from memory along the data bus into the MDR; the PC is incremented to point at the next instruction; and the contents of the MDR are copied into the CIR. In the decode stage, the Control Unit decodes the instruction now held in the CIR, working out the operation required (the opcode) and the data or address it acts on (the operand). In the execute stage, the instruction is carried out — this might be an ALU calculation writing a result to the accumulator, a data transfer, or a jump that overwrites the PC to redirect program flow.

A frequently rewarded point is the order of incrementing the PC: it happens during the fetch stage, before execution, which is exactly why a jump or branch instruction can legitimately overwrite the PC during the execute stage to change the flow of control. The register-transfer notation for the cycle is worth rehearsing because writing it out correctly demonstrates the precise understanding examiners are looking for:

MAR <- [PC]
PC  <- [PC] + 1
MDR <- [memory at MAR]
CIR <- [MDR]

Worked example: tracing the cycle through two instructions

The best way to make the register transfers stick is to trace them against real memory. Suppose a tiny program is loaded from address 100 onwards, the PC currently holds 100, and memory contains ADD 50 at address 100 and STA 60 at address 101. Value 7 is stored at address 50, and the accumulator holds 12. Watch the registers move on the first instruction:

• Fetch. MAR ← [PC], so the MAR becomes 100. The PC is incremented, so PC ← 101 — this happens now, in fetch, not later. The control bus asserts the read line; the word at address 100 travels along the data bus into the MDR, so MDR ← "ADD 50". Finally CIR ← [MDR], so the CIR holds ADD 50.
• Decode. The Control Unit splits the CIR contents into opcode and operand: opcode ADD, operand 50. It recognises ADD as "fetch the value at the operand address and add it to the accumulator", so it knows a further memory read is needed.
• Execute. The operand 50 is placed in the MAR, the value at address 50 (7) is read into the MDR, and the ALU computes 12 + 7 = 19, writing the result to the accumulator. ACC ← 19.

The cycle then repeats with the PC already pointing at 101, so STA 60 (store the accumulator to address 60) is fetched next. Being able to narrate this — naming which register holds what at each step — is exactly the "describe how the FDE cycle executes this instruction" answer that scores full marks. A common mistake is to increment the PC in the execute stage, or to forget that a direct-addressed data-processing instruction like ADD needs a second memory access in execute to fetch its operand.

Interrupts and the cycle

The idealised cycle above runs uninterrupted, but real processors must respond to events — a key press, a disk finishing a transfer, a timer expiring. At the end of each execute stage the processor checks for a pending interrupt; if the interrupt's priority is high enough, it saves the current register contents (crucially the PC) onto a stack, loads the address of the appropriate interrupt service routine (ISR), runs the ISR, then restores the saved registers and resumes exactly where it left off. This interrupt-driven model is why a computer can appear to do many things at once without wasting cycles constantly polling every device, and it is the hardware mechanism the operating system's input/output management relies on — a thread picked up in the operating system functions lesson.

Processor Types

The processor types lesson develops the factors affecting CPU performance and the two competing instruction-set design philosophies. Three factors are examined as influences on performance. Clock speed, measured in hertz, sets how many cycles the processor performs per second; a higher clock speed means more instructions per second, but it cannot be raised indefinitely because of heat dissipation. The number of cores allows genuinely parallel execution — a quad-core processor can in principle execute four instruction streams at once — though the speed-up is limited by how well a task can be divided and by software that may not be written to exploit multiple cores. Cache is small, fast memory on or near the CPU that holds frequently used instructions and data; more cache, and a sensible hierarchy of levels (L1, L2, L3), reduces the time the processor spends waiting on slower main memory.

The lesson then contrasts CISC (Complex Instruction Set Computer) and RISC (Reduced Instruction Set Computer). CISC processors provide a large set of complex, variable-length instructions, some of which take many clock cycles; the aim is to do more work per instruction and keep programs short. RISC processors provide a small set of simple, fixed-length instructions that each typically execute in a single cycle; complexity moves into software, and the regularity makes techniques such as pipelining far easier to implement.

Feature	CISC	RISC
Instruction set	Large, complex	Small, simple
Instruction length	Variable	Fixed
Cycles per instruction	Often many	Typically one
Complexity location	Hardware	Software/compiler
Pipelining	Harder	Easier
Typical use	Desktop/legacy compatibility	Mobile, embedded, low-power

The connection to the wider course is that the RISC design choice of fixed-length single-cycle instructions is precisely what makes the pipelining covered next so effective, and the trade-off between hardware and compiler complexity reappears in translators.

Worked example: reasoning about clock speed and cores

Performance questions often look like arithmetic but are really about understanding why the arithmetic misleads. Take a naive model where a single core running at a clock speed of $3\,\text{GHz}$3GHz retires one instruction per cycle. The instructions per second is:

$3 \times 10^9 \text{ cycles/s} \times 1 \text{ instr/cycle} = 3 \times 10^9 \text{ instructions/s}$3×109 cycles/s×1 instr/cycle=3×109 instructions/s

Now double the clock speed to $6\,\text{GHz}$6GHz and, separately, consider adding a second core at the original $3\,\text{GHz}$3GHz. On paper both changes "double" throughput to $6 \times 10^9$6×109 instructions per second. The examinable insight is that these are not equivalent in practice:

• Raising clock speed is limited by heat dissipation — power consumption rises steeply with frequency, so you hit a thermal wall.
• Adding a core only delivers the full doubling if the workload can be split into independent streams. A sequential task, or software not written for concurrency, sees little gain — the point captured by Amdahl's law, that parallel speed-up is capped by the fraction of the program that must run serially.

So the correct answer to "why not just keep increasing clock speed?" is heat and power, and to "why doesn't a quad-core run every program four times faster?" is that the speed-up depends on how divisible the task is and whether the software exploits the cores. Cache improves real performance in a third way — by reducing how often the processor stalls waiting on main memory — so a strong "how would you improve this processor?" answer names all three levers.

Addressing modes

H446 also expects you to distinguish how the operand of an instruction is interpreted — the addressing mode. The same opcode can mean different things depending on the mode, and this is a reliable short-answer item. The four modes to know are:

Mode	The operand is...	Example meaning
Immediate	the actual value to use	ADD #7 adds the literal 7
Direct	the address of the value	ADD 50 adds the value stored at address 50
Indirect	the address of a location that holds the address of the value	ADD (50) — read address 50 to get a pointer, then add the value there
Indexed	a base address to which an index register is added	ADD 50,X adds the value at address 50 + [index register]

Immediate addressing is fastest because no memory access is needed to obtain the operand; indirect addressing is the slowest of the four because it requires two memory reads before the ALU can even begin. Indexed addressing is the natural tool for stepping through an array, since incrementing the index register walks through consecutive elements — a direct link to how the data structures in Data Structures are laid out in memory. A frequent mistake is to conflate immediate and direct: remember that the # (or an explicit "the value") signals immediate, and a bare number signals a memory address.

Pipelining

The pipelining lesson explains how a processor improves throughput by overlapping the stages of the fetch-decode-execute cycle for consecutive instructions. Without pipelining, the processor finishes executing one instruction before fetching the next, leaving most of the hardware idle at any moment. With pipelining, while one instruction is being executed, the next can be decoded and the one after that fetched — so on each clock cycle a new instruction enters the pipeline and (once the pipeline is full) a completed instruction leaves it.

The performance benefit is increased instruction throughput rather than a faster individual instruction: each instruction still takes the same time end to end, but the processor completes more of them per unit time because the stages run in parallel. The lesson is careful to distinguish this from raising clock speed or adding cores — pipelining extracts more work from the existing cycle by keeping every stage busy.

Worked example: quantifying the throughput gain

Numbers make the benefit concrete. Suppose each of the three stages (fetch, decode, execute) takes one clock cycle, and we run five instructions.

• Without pipelining, each instruction occupies the processor for all three cycles before the next begins: $5 \times 3 = 15$5×3=15 cycles.
• With a three-stage pipeline, the first instruction takes 3 cycles to reach the end (the pipeline "fill" latency), and after that a new instruction completes every cycle. Total: $3 + (5 - 1) = 7$3+(5−1)=7 cycles.

The general result for $n$n instructions in a $k$k-stage pipeline is $k + (n - 1)$k+(n−1) cycles, approaching one instruction per cycle as $n$n grows large. The exam point hidden in these numbers: the latency of any individual instruction is unchanged — it still takes three cycles end to end. What improves is throughput, the instructions completed per unit time. Candidates who claim pipelining "makes each instruction faster" lose the mark; the correct phrasing is that it "increases throughput by overlapping stages".

Pipeline hazards

The standard exam point is the pipeline hazard, and it is worth knowing the three families rather than only the branch case:

• Control (branch) hazards — the headline case. If the processor has speculatively fetched and decoded the instructions following a conditional jump, and the jump is then taken, those partially processed instructions must be discarded and the pipeline refilled from the new address — a "pipeline flush" or "stall" that temporarily wipes out the benefit. Branch prediction exists precisely to reduce how often this happens.
• Data hazards — an instruction needs the result of one still moving through the pipeline ahead of it (for example, it reads a register the previous instruction has not yet written back).
• Structural hazards — two instructions need the same hardware resource in the same cycle.

Being able to explain both the gain (overlapping stages raises throughput) and the limitation (hazards, especially the branch flush, erode it) is what separates a full-mark answer from a partial one. It also explains, synoptically, why RISC's fixed-length instructions matter: uniform instructions make the pipeline stages predictable and hazards easier to manage than the variable-length instructions of a CISC design.

Input Devices

The input devices lesson surveys how data is captured and converted into a form the processor can work with, and — crucially for the exam — how to justify the choice of an input device for a specific application. Rather than memorising a long catalogue, the productive approach is to reason from the scenario to the requirements (speed, accuracy, environment, volume, cost) and then to the device.

Worked examples on this topic typically present a context — a supermarket checkout, a library, a tablet for a graphic artist, a high-volume form-processing bureau — and ask which input method is most appropriate and why. A barcode scanner suits the checkout because it captures a product identifier quickly and accurately without manual keying; OMR (Optical Mark Recognition) suits multiple-choice forms because it reads the position of marks at high volume; OCR (Optical Character Recognition) suits the conversion of printed text into editable data; a graphics tablet with a stylus suits an artist because it captures pressure and fine positional detail. The transferable skill — selecting and justifying technology against a set of requirements — is exactly the analytical move rewarded throughout Component 01.

Output Devices

The output devices lesson applies the same scenario-driven reasoning to how processed data is presented back to the user or the physical world. The examinable skill is again justification: matching the output characteristics (resolution, colour fidelity, durability, volume, three-dimensionality) to the requirement.

The lesson distinguishes the operating principles of common technologies — for example, an inkjet printer building an image by spraying droplets, suited to photo-quality colour at low volume, versus a laser printer using a charged drum and toner, suited to fast high-volume monochrome printing. It also covers the increasingly examined area of actuators in control systems and 3D printers (additive manufacturing that builds objects layer by layer from a digital model), which connects directly to the output side of the embedded systems lesson. The recurring exam pattern is to give a context and demand a justified recommendation rather than a bare list of device names.

Primary Storage

The primary storage lesson covers the memory the processor can address directly: RAM, ROM, cache and virtual memory. RAM (Random Access Memory) is volatile — it loses its contents when power is removed — and holds the programs and data currently in use; it is the working memory the operating system manages, a theme developed in memory management. ROM (Read-Only Memory) is non-volatile and holds firmware such as the bootstrap loader that starts the machine; its contents persist without power.

Cache sits between the processor and main memory, holding copies of frequently accessed instructions and data so the CPU spends less time waiting; the principle of locality of reference is what makes it effective. Locality has two forms worth naming in an answer: temporal locality (data used recently is likely to be used again soon — think of a loop counter) and spatial locality (data near recently-used data is likely to be needed soon — think of the next element of an array). Cache is arranged in levels: L1 is smallest and fastest and sits on the core; L2 is larger and slightly slower; L3 is larger still and often shared between cores. When the processor needs data, it checks L1, then L2, then L3, then main memory — a "cache hit" avoids the slow trip to RAM, a "cache miss" incurs it. This is why more cache and a well-designed hierarchy improve real performance in a way that a headline clock-speed figure does not capture.

Virtual memory is the technique of using a portion of secondary storage as an extension of RAM so that programs larger than physical memory can run; pages are swapped between disk and RAM as needed. Excessive swapping — "disk thrashing" — degrades performance, which is the bridge to the operating-system view of memory in memory management, where the paging and segmentation mechanisms that implement it are examined in full. The single most examined distinction here is volatile versus non-volatile, so make sure you can classify each memory type confidently: RAM and cache are volatile; ROM and all secondary storage are non-volatile. A recurring trap is describing cache as "the same as RAM but faster" — the mark is for identifying it as a separate, smaller tier that exploits locality, not merely faster main memory.

Secondary Storage

The secondary storage lesson develops non-volatile long-term storage and the three physical principles by which it works. Magnetic storage, such as a hard disk drive, stores data as patterns of magnetisation on spinning platters read by a moving head; it offers large capacity at low cost per gigabyte but has moving parts and slower access. Optical storage, such as CD, DVD and Blu-ray, stores data as pits and lands on a reflective surface read by a laser; it is cheap and portable but lower in capacity and slower than the alternatives. Solid-state storage, such as an SSD or flash drive, stores data as charge in NAND flash memory cells with no moving parts; it is fast, robust and silent but historically more expensive per gigabyte.

The lesson stresses that examiners want the operating principle, not just the name — being able to say that an SSD uses flash memory cells while an HDD uses magnetised platters is what earns the marks in a "describe how" question. These principles set up the comparison and selection skills consolidated in the next lesson.

Storage Comparison

The storage comparison lesson brings the storage types together so you can select the right one for a scenario against the key criteria: capacity, speed, cost per gigabyte, portability, durability and longevity. This is the storage equivalent of the input/output justification skill, and a reliable extended-answer question.

Type	Principle	Speed	Cost/GB	Durability	Typical use
Magnetic (HDD)	Magnetised platters	Moderate	Low	Moving parts, less robust	Bulk/backup storage
Optical (DVD/Blu-ray)	Pits and lands, laser-read	Slow	Low	Scratch-prone	Distribution, archival
Solid-state (SSD)	Flash memory cells	Fast	Higher	No moving parts, robust	OS drive, mobile devices

The transferable exam technique is to read the scenario for its dominant constraint — a data centre prioritising capacity per pound may favour magnetic; a laptop prioritising speed and shock resistance favours solid-state; a one-off mass distribution of read-only data favours optical — and to justify the recommendation against that constraint rather than reciting all the properties of every medium.

Embedded Systems

The embedded systems lesson ties the module together by examining computers built into larger devices to perform a dedicated function — the controller in a washing machine, the engine management unit in a car, the avionics in an aircraft, the controller in a digital camera. An embedded system is designed for one task or a small set of tasks, which lets it be optimised for low power consumption, small size, low cost and high reliability rather than the general-purpose flexibility of a desktop machine.

This lesson is where several earlier threads converge. Embedded systems frequently use the Harvard architecture introduced in the CPU architecture lesson and RISC processors from the processor types lesson because their predictability and low power suit a dedicated controller; they read from sensors (input) and drive actuators (output); and they typically run firmware from ROM. The examinable theme is the trade-off: a dedicated design gains efficiency and reliability at the cost of flexibility, and recognising that trade-off in a given device is the core of the question.

How to Revise Processors & Hardware

The fastest, most durable revision win on this module is to draw the fetch-decode-execute cycle from memory, with the correct register transfers, until you can reproduce it without prompts — including the detail that the PC is incremented during fetch and may be overwritten during execute by a jump. Pair that with a labelled CPU diagram (ALU, CU, the five registers, the three buses) and you have covered the recall heart of the topic.

For the comparison content — Von Neumann versus Harvard, CISC versus RISC, the three storage principles, primary versus secondary storage — build a one-line distinction for each pair and rehearse it as a flashcard, then practise applying it to scenarios, because Component 01 rarely asks for a property in isolation and almost always asks you to justify a choice. Three blank-page redraws of the cycle plus a dozen scenario-justification questions over a week will embed this far more reliably than passive rereading.

Exam Technique: Answering Component 01 Hardware Questions

Knowing the content is necessary but not sufficient — Component 01 marks are earned by matching your answer to the command word and the mark allocation. A few tactics recur across this whole module.

Read the command word and let it set the depth. "State" or "Identify" wants a single term (the name of a register, the type of a bus) and no elaboration — spending three sentences on a one-mark "state" question wastes time you need later. "Describe" wants what something does; "Explain" wants why or how, with a causal chain; "Compare" demands explicit both-sides statements, not two separate descriptions. On a "compare CISC and RISC" question, a sentence that mentions only RISC scores nothing on the comparison — you must write "RISC uses fixed-length instructions whereas CISC uses variable-length", pairing the two on each axis.

Count the marks and supply that many distinct points. A six-mark "explain how the fetch-decode-execute cycle operates" question is signalling roughly six creditworthy statements. Map them out: the PC-to-MAR transfer, the memory read into the MDR, the PC increment, the MDR-to-CIR transfer, the decode into opcode and operand, and the execute action. One clean sentence per point beats a dense paragraph a marker has to unpick.

Use the exact register names. "A register holds the address" is worth far less than "the Memory Address Register holds the address". The precise vocabulary is the mark. The same applies to buses — name the address, data and control bus and state the direction (address bus unidirectional, data bus bidirectional).

On justification questions, name the dominant constraint first. For a storage or device-choice scenario, open with the constraint the scenario emphasises ("the priority is shock resistance and speed for a mobile device") then justify the choice against it ("therefore solid-state — no moving parts and faster access than an HDD"). This structure earns the AO3 application marks a bare property list misses.

Common Mistakes to Avoid

These are the slips that most reliably cost marks on the processors and hardware topic:

• Swapping the MAR and the MDR. The MAR holds an address; the MDR holds data or an instruction. Mixing them up is the single most common register error.
• Incrementing the PC in the wrong stage. The PC is incremented during fetch, not execute. This is precisely what allows a jump instruction to overwrite it during execute.
• Claiming pipelining makes each instruction faster. It raises throughput, not the latency of an individual instruction.
• Treating clock speed as the only performance lever. A strong answer weighs clock speed and number of cores and cache — and knows why clock speed alone can't scale (heat).
• Reciting device properties instead of justifying a choice. Scenario questions reward matching characteristics to the stated requirement, not listing everything you know about every device.
• Describing storage by name only. "Describe how an SSD stores data" needs the operating principle (charge held in NAND flash memory cells), not just "it's solid-state".
• Confusing volatile and non-volatile. RAM and cache lose their contents without power; ROM and secondary storage do not. Classify confidently.

Mini-FAQ

Is the accumulator one of the "five registers"? Yes — the ACC holds intermediate ALU results, alongside the PC, MAR, MDR and CIR. Some textbooks also mention a Status Register (flags) and general-purpose registers; know the core five precisely and recognise the others.

Von Neumann versus Harvard — which is "better"? Neither in the abstract. Von Neumann's single shared memory is simpler and cheaper and dominates general-purpose computing; Harvard's separate instruction and data buses avoid the bottleneck and suit embedded systems and digital signal processors. The mark is for stating the trade-off, not picking a winner.

Do I need to memorise specific storage capacities or speeds? No — avoid quoting precise figures that date quickly. Examiners reward the operating principle, the relative ordering (SSD faster than HDD faster than optical), and correct justification against a scenario, not numbers like "a 2 TB drive".

How much maths is in this topic? Light but real: the addressable-memory relationship ($2^n$2n locations for an $n$n-line address bus), simple instructions-per-second reasoning, and the pipeline cycle count $k + (n-1)$k+(n−1). Show the relationship you are using.

Where does this connect synoptically? The interrupt mechanism links to operating system functions; virtual memory links to memory management; addressing modes and instruction sets link to the assembly work in Programming. Flagging one such link in an extended answer signals the cross-topic understanding A-Level rewards.

Start at the Processors & Hardware course and work through all ten lessons in order, from CPU architecture to embedded systems. Once the machine is fluent, the rest of the OCR A-Level Computer Science path — beginning with Software & Systems and the operating system that manages exactly this hardware — falls into place as software making use of the processor you can now describe.

Related Reading

• OCR A-Level Computer Science: Software & Systems — Complete Revision Guide
• OCR A-Level Computer Science: Data Representation — Complete Revision Guide
• OCR A-Level Computer Science: Boolean Algebra — Complete Revision Guide
• OCR A-Level Computer Science: Programming — Complete Revision Guide
• OCR A-Level Computer Science: Networks — Complete Revision Guide