One tiny loop, repeated a billion times
In the last guide we saw the layers of abstraction that turn an app into electricity, and before that the von Neumann model: one control unit plus a datapath, wired to memory that holds both the program and its data. Now we zoom into the moment-by-moment life of that machine. Strip away the operating system, the compiler, the billions of transistors, and underneath a processor is doing one astonishingly simple thing in a tight loop. It is not thinking. It is not reasoning. It is just repeating three steps so fast that the result looks like intelligence.
Those three steps are fetch, decode, and execute — together the instruction cycle. Fetch: go to memory and grab the next instruction. Decode: figure out what kind of instruction it is and what it needs. Execute: actually do it — add two numbers, load a value, jump somewhere else. Then the loop starts over, with the next instruction. That's it. A modern CPU runs this cycle billions of times every second, and every program you have ever used — a game, a browser, this very page — is nothing but a long list of instructions being chewed through one bite at a time.
The program counter: a finger on the line you're reading
How does the CPU know which instruction is next? It keeps a special register called the program counter (PC) that holds the memory address of the next instruction to fetch. Think of it like the finger you run along a line of a recipe so you don't lose your place: it always points at the step you're about to do. Each instruction lives at an address in memory, just like a house has a street number, and the PC simply holds the address of the one coming up.
After each fetch, the PC quietly advances to the next instruction — usually just by adding the size of one instruction to its current value. If instructions are four bytes wide (a common choice on a RISC-V machine), the PC steps forward by 4 each time, marching straight down through memory. That steady march is what makes a program run top to bottom by default. The interesting cases — loops, if-statements, function calls — are exactly the moments when something overwrites the PC with a different address instead of letting it step by 4. A branch is nothing more mysterious than a write to the program counter.
Walking one instruction all the way through
Let's trace a single instruction end to end so the loop becomes concrete. Say the next instruction is "add the numbers in registers x5 and x6, and put the result in x7." The control unit orchestrates a fixed sequence of moves, pulling the right levers in the datapath at the right moment. Here is that sequence, the same shape for almost every instruction, with only the execute step changing depending on what the instruction asks for.
- Fetch: read the instruction stored at the address in the program counter, pulling its bits out of memory into the CPU. Then bump the PC forward (say +4) so it already points at the following instruction.
- Decode: the control unit inspects the instruction's bits — its opcode (the field that says "this is an add") and the fields naming x5, x6, x7. It reads the current values out of x5 and x6 from the register file. Now the machine knows exactly what to do and to whom.
- Execute: the arithmetic logic unit (ALU) actually adds the two values. This is the step that differs by instruction — a load would compute a memory address here instead, a branch would compare two values.
- Write back: the sum is written into register x7, where the program can use it later. The loop is done; the control unit goes back to step 1 with the already-updated PC.
Notice how much of the work is the same regardless of the instruction: fetch and decode are nearly identical for an add, a load, or a branch. That sameness is a gift to hardware designers. Because the early stages don't depend on what the instruction does, they can be built once and reused for every instruction — and, as we'll see in later rungs, they can be overlapped across instructions like an assembly line, which is where pipelining comes from.
The clock: the drumbeat that keeps everyone in step
What stops the CPU from racing ahead and reading a register before the ALU has finished writing it? A heartbeat called the clock. The hardware has a tiny oscillator that ticks at a fixed rate, and every clock cycle is one tick of that drum. On each tick, results that have settled are allowed to move forward into the next stage; between ticks, the logic is busy computing but nothing is committed. The clock is what keeps thousands of tiny operations marching in lockstep instead of trampling each other.
The number of ticks per second is the clock rate — 3 GHz means three billion ticks every second. It is tempting to read that as raw speed, but here is the first honest warning of this ladder: a higher clock rate alone does not mean a faster computer. This is the famous "megahertz myth." A chip that ticks faster but needs more ticks per instruction, or runs a clumsier program, can easily lose to a slower-ticking rival. Speed is never one number.
From the cycle to the iron law of performance
Now that you've watched one instruction crawl through the cycle, a real performance formula falls right out of it. The total time a program takes on the CPU is simply how many instructions it runs, times how many cycles each one costs on average, times how long a cycle lasts. That product is the iron law of performance, and it is the single most useful equation in this whole field:
CPU time = instruction count x CPI x cycle time | | | | | how many instructions | seconds per tick (= 1 / clock rate) | the program runs | | average cycles | per instruction total seconds on the CPU
Each of the three terms is a dial a designer (or a programmer) can turn, and the iron law shows why no single one settles the race. Cranking the clock rate shrinks the cycle time but does nothing to instruction count or CPI — and may even push CPI up if the rest of the machine can't keep up. A smarter compiler can cut instruction count. Pipelining (a later rung) drives down effective CPI. The art of computer architecture is balancing all three at once, and one of its oldest maxims is to make the common case fast: spend your effort speeding up the instructions that actually run most often.
And here is the deeper reason the iron law has dominated the field for the past two decades. For a long time, hardware got faster almost for free: every couple of years transistors shrank, clock rates climbed, and the same program just ran quicker. But around 2005 that free lunch ended — chips hit a power-and-heat wall, clock rates stopped climbing, and the cycle-time dial mostly jammed. With one dial stuck, designers were forced to attack instruction count and CPI instead, and to run many cycles in parallel across multiple cores. That single shift is why the rest of this ladder exists: caches, pipelines, parallelism and accelerators are all the field's answer to a clock that stopped getting faster on its own.