From rewiring to remembering
In the first guide you saw that computer architecture is the study of how to turn a pile of switches into a machine that runs the programs people actually write. The earliest electronic computers ran programs the hard way: to change what the machine did, engineers physically replugged cables and flipped banks of switches for hours or days. The machine and the program were one thing. Change the program and you rebuilt the machine.
The breakthrough was the stored-program concept: store the instructions of a program in the same read/write memory that already holds the data, encoded as numbers just like any other number. Now changing the program means writing different numbers into memory — a few seconds, not a few days. The stored-program idea is what makes one physical machine able to be a word processor this minute and a chess engine the next. The hardware stays fixed; the numbers in memory decide everything.
The four-box picture: the von Neumann model
The standard sketch of a stored-program computer is the von Neumann model: a CPU, a single memory, an I/O system for the outside world, and buses — shared wires — connecting them. The CPU itself splits into two halves. The control unit is the conductor: it decides what happens next and sends the signals that steer everything. The datapath is the orchestra: the registers, the arithmetic unit, and the wires that actually carry and crunch the numbers.
+---------------------------- CPU ----------------------------+
| |
| CONTROL UNIT --- control signals ---> DATAPATH |
| (decides what) (registers, ALU) |
| |
+-------------------------------+-----------------------------+
|
====== B U S ====== <-- one shared road
|
+--------------------+--------------------+
| |
+--------+ +-----------+
| MEMORY | (instructions AND data) | I/O |
+--------+ +-----------+There is one quietly important consequence of that picture. Both the next instruction and the data it needs come from the same memory over the same bus, one item at a time. That single shared doorway — every instruction and every datum squeezing through it in turn — is the famous von Neumann bottleneck. No matter how fast the CPU thinks, it can only be fed as fast as that one road allows. Much of the rest of this ladder is, honestly, a long campaign to widen, bypass, or hide that doorway.
Harvard, and why the line is blurry
An honest model needs its cousin. The Harvard architecture keeps instructions and data in two separate memories with two separate buses, so the CPU can fetch an instruction and read a datum in the same instant. It dodges the bottleneck — at the cost of being less flexible (a program cannot so easily treat its own code as data). The two designs are often drawn as rivals, but that framing oversimplifies reality.
How it actually runs: the instruction cycle
Given a memory full of instruction-numbers, how does the machine make progress? It repeats a tiny ritual called the instruction cycle, or fetch-decode-execute. A special register, the program counter, holds the address of the next instruction to run. The CPU loops over the same handful of steps forever, and that relentless loop is all a computer ever really does.
- Fetch: read the instruction at the address in the program counter, pulling it from memory across the bus into the CPU.
- Decode: the control unit looks at the instruction's bits and works out what it means — an add? a load from memory? a jump? — and raises the right control signals.
- Execute: the datapath does the work — the arithmetic unit adds, or an address is computed and memory is read or written.
- Advance: update the program counter (usually to the very next instruction, unless this one was a branch that redirected it), then loop back to fetch.
That is the whole engine. Guide 4 of this rung walks one instruction through these stages in close-up; later rungs reveal that real CPUs overlap many instructions at once, like a laundry assembly line washing one load while drying another. But the illusion the model promises is precious and it is kept: results appear to happen one instruction at a time, in the order you wrote them, even when the hardware secretly does otherwise.
Bits, words, the clock — and a first honest look at speed
Everything above moves in fixed-size chunks. A bit is one 0/1; eight bits make a byte; and a word is the natural mouthful the machine handles at once — 32 or 64 bits on the CPUs in your phone and laptop. Registers, addresses and the arithmetic unit are all sized in words, which is why you hear a machine called "64-bit". Meanwhile a steady clock ticks beneath it all, and each tick — a clock cycle — is the heartbeat that nudges the instruction cycle forward one notch.
It is tempting to judge a CPU by its clock rate alone — "this one is 4 GHz, it must be faster." That is the megahertz myth, and it is wrong. The honest accounting is the iron law of performance: CPU time = instruction count x CPI x cycle time, where CPI is the average cycles per instruction and cycle time is one over the clock rate. A higher clock shrinks only cycle time; a sloppy compiler that emits more instructions, or a design with worse CPI, can easily erase that gain. All three factors matter, and they trade against one another.
For decades you could ignore all this because the clock just kept rising on its own. No longer. Moore's law — that the number of transistors on a chip roughly doubles every couple of years — still limps along but is clearly slowing. The cruel partner was Dennard scaling, the rule that as transistors shrank they also got proportionally cooler and cheaper to switch; it effectively ended around 2005. Once chips could no longer simply run faster without melting, the industry pivoted hard to many cores and specialised accelerators. That pivot — why hardware stopped speeding up on its own — is the reason almost everything in the later rungs of this ladder exists.