HookThe 1945 memo that every processor still obeys
In June 1945 the mathematician John von Neumann circulated a typed memo with the unglamorous title First Draft of a Report on the EDVAC. Buried in it was an idea so durable that the phone in your pocket, the console under your television and the laptop you revise on all still obey it: keep the program and the data in the same memory, and have the machine work through its instructions one at a time. We call any computer built this way a stored-program, or Von Neumann, machine, and the OCR J277 course is at heart a tour of how one actually runs.
The central processing unit (CPU) is the component that does the working-through. Its whole job is to fetch instructions from memory, decode what they mean and execute them, billions of times a second, in a loop that never stops while the machine is on. Section 1.1 asks you to do three things with that idea: name the parts of the CPU and say what each one does, explain what makes one CPU faster than another, and recognise the millions of hidden CPUs sitting inside washing machines and car engines that never call themselves computers at all.
ModelThe parts of a CPU and what each one holds
A CPU is not one thing but a small team of specialised parts on a single chip. The control unit (CU) is the manager: it fetches each instruction, decodes it and sends timing and control signals to everything else so the steps happen in the right order. The arithmetic logic unit (ALU) is the calculator: it performs the actual sums such as add and subtract, and the logic operations such as AND, OR and comparisons like whether one value is bigger than another. Cache is a small pool of very fast memory built onto the CPU itself; because reaching out to main memory is comparatively slow, the CPU keeps recently used instructions and data in cache so it does not have to wait for them twice.
The parts that do the moment-to-moment holding are the registers - tiny, extremely fast stores inside the CPU, each with a fixed job. The Von Neumann model names four you must know. The program counter (PC) holds the memory address of the next instruction to fetch. The memory address register (MAR) holds the address the CPU wants to read from or write to. The memory data register (MDR) holds the data or instruction just fetched from that address, or about to be written to it. The accumulator (ACC) holds the result of whatever the ALU just calculated. Data travels between the CPU and memory along the buses: the address bus carries the location, the data bus carries the contents.
MechanismThe fetch-execute cycle, register by register
Every program, however complicated, is run by repeating one simple loop: fetch, decode, execute. In the fetch stage the CPU copies the address in the program counter into the MAR, the control unit signals memory to read, and the instruction stored at that address travels back along the data bus into the MDR. The program counter is then incremented so it already points at the following instruction. In the decode stage the control unit works out what the instruction means, splitting it into an opcode (the operation, such as LOAD or ADD) and an operand (the data or address it acts on). In the execute stage the CPU actually carries the instruction out, which may mean loading a value into the accumulator, doing a calculation in the ALU, or storing a result back to memory. Then the loop starts again, and again, at the speed of the clock.
The reason exam questions push so hard on the registers is that each one has exactly one role, and mixing them up is the classic way to drop marks: the PC says where to go next, the MAR names where, the MDR carries what, and the ACC keeps the answer.
Suppose the program counter holds address 64. Fetch: 64 is copied into the MAR; the control unit raises a read signal; the instruction stored at address 64 - say LOAD 128 - is returned along the data bus into the MDR; the program counter is incremented to 65. Decode: the control unit splits LOAD 128 into the opcode LOAD and the operand 128. Execute: LOAD means copy the contents of that address into the accumulator, so 128 goes into the MAR, the value living at address 128 - say 7 - is fetched into the MDR, and 7 is copied into the accumulator. The ACC now holds 7, the PC holds 65, and the cycle repeats with the next instruction. Trace tables in the exam work exactly like this: one row per step, one column per register, and the mark is for showing the PC incrementing at the right moment.
DataWhat actually makes one CPU faster
Three characteristics decide how much work a CPU gets through, and OCR wants you to explain the mechanism behind each, not just list them. Clock speed is how many cycles the CPU ticks through per second, measured in hertz; a 3.2 GHz chip ticks 3.2 billion times a second, and because instructions are paced by the clock, a higher clock generally means more instructions executed each second. Cache size matters because cache is the fast memory nearest the core: the more of it there is, the more instructions and data the CPU can keep close by, and the less often it has to stall waiting for slow main memory. Modern chips have several levels - L1 is smallest and fastest, L3 largest and slightly slower. Number of cores is how many complete processing units share the chip; a quad-core CPU can genuinely work on four instructions at once.
The evaluation examiners reward is that none of these scales for free. Doubling the clock speed roughly doubles heat and power draw, which is why phones lean on cores and cache instead of raw gigahertz. And extra cores only help software that has been written to split its work across them - a single-threaded task runs no faster on eight cores than on one.
A CPU rated at 3.2 GHz completes 3,200,000,000 clock cycles every second. If it averages one instruction per cycle, that is roughly 3.2 billion instructions a second. Add a second core and the theoretical ceiling doubles to 6.4 billion - but only for programs written to run across two cores; a game's single-threaded main loop still rides one core and sees no gain at all. Double the clock to 6.4 GHz instead and every task speeds up, yet the chip now draws far more power and runs much hotter, which is the trade-off that keeps laptop and phone clock speeds roughly where they are.
CaseEmbedded systems: the computers nobody calls computers
An embedded system is a computer built into a larger device to do one dedicated job, rather than a general-purpose machine that runs whatever software you install. The washing machine choosing a spin speed, the engine management unit trimming your car's fuel mixture, the controller in a pacemaker, a digital camera's image processor, a set of traffic lights, a microwave's timer - all are embedded systems. Each still has a CPU, memory and a program, but the program is fixed in ROM and the hardware is stripped back to exactly what the one task needs.
The characteristics OCR wants you to draw out all follow from that single purpose. Embedded systems are typically small, low-power and cheap, because they are mass-produced inside another product. They are reliable and need little or no maintenance, because the software rarely changes. They usually have no general keyboard or screen - input arrives from sensors and output goes to motors, lights or a small built-in display. And because they do one job, they can be highly optimised: a dishwasher's controller does not need a fast quad-core CPU or gigabytes of RAM, so it does not have them. The trade-off is flexibility - you cannot install new apps on your fridge, and a design fault baked into ROM is hard to fix once the product has shipped.
CaseReading a real specification sheet
Put the three ideas together against a real chip. The Raspberry Pi 4 that sits in a lot of school computing labs runs a Broadcom BCM2711 processor: a quad-core ARM Cortex-A72 clocked at 1.5 GHz, with three levels of cache. Read that specification the way an exam question wants you to. Four cores means it can genuinely run four threads of a program in parallel - handy for a web browser rendering a page while a download runs in the background. The 1.5 GHz clock is modest next to a 4 GHz desktop chip, so each core does less per second; the Pi wins on price and power efficiency, not on raw speed. And the cache is what stops those cores constantly stalling on the Pi's comparatively slow main memory.
Now notice where architecture meets embedded systems. That same ARM Cortex family, stripped down, is what powers billions of phones, smart speakers and car systems as embedded processors. The difference is not the fetch-execute cycle - that is identical everywhere - but how the chip is packaged, clocked and tied to a single job. A question that hands you a device and asks whether you would use a general-purpose or an embedded processor, and why, is really asking you to weigh cost, power, flexibility and the number of jobs the device actually has to do.
VocabularyKey terms the mark scheme pays for
TrapsMisconceptions that cost marks
ExamWhat examiners want
Paper 1 (J277/01) rewards precision. On AO1 recall, a register question wants the exact role, not a vague one: state that the PC holds the address of the next instruction, not that it 'controls the program'. When a question says describe the fetch-execute cycle, structure your answer as fetch, then decode, then execute, and name the registers touched at each stage - a trace table earns the mark for showing the program counter increment at the right point.
Watch the command words. State or identify is one mark for a fact; describe wants what happens; explain wants a reason (higher clock speed means more cycles per second therefore more instructions executed). The 6- and 8-mark levelled questions on CPU performance or general-purpose versus embedded systems are marked on development: do not just list clock speed, cache and cores - link each characteristic to an effect and then to a consequence, and weigh a trade-off such as heat, power or cost. Finish an embedded-systems answer by tying the characteristics (small, low-power, reliable, fixed ROM software) back to the specific device in the question rather than reciting them in the abstract.