The Fetch–Decode–Execute Cycle

A program is just a long list of very small instructions, sitting in the computer's main memory (RAM). On its own that list does nothing — it's like a recipe left on the counter. Something has to actually read each line and do it. That something is the CPU (the central processing unit — the "brain" of the computer).

The remarkable thing is how it does it. The CPU doesn't read the whole program and understand it all at once. It repeats one tiny, mindless routine over and over:

Fetch — go and get the next instruction from memory.
Decode — work out what that instruction is asking for.
Execute — actually do it.

…then it loops straight back to step 1 and fetches the next instruction. This never-ending loop is called the fetch–decode–execute cycle (sometimes the instruction cycle), and a modern CPU spins through it billions of times every second. Everything your computer ever does — showing this page, playing a game, running a video call — is nothing more than this same three-step cycle, repeated an unimaginable number of times.

Watch the loop go round

Picture two parts talking to each other: main memory on the left holds the instructions, and the CPU on the right runs the cycle. Step through it and watch one instruction travel from memory into the CPU and get carried out — then see the loop start again for the very next instruction.

Notice that fetch always reaches into memory to bring the instruction across, and that after execute the arrow curls right back to fetch. There is no "finished" — the cycle just keeps turning until the computer is switched off.

What each step really does

Each step has a clear job. It helps to know that the CPU keeps a special counter, the program counter (PC), which always holds the memory address of the next instruction to fetch.

For every instruction, the CPU carries out these three stages in this fixed order:

Fetch — the CPU looks at the program counter to find the address of the next instruction, copies that instruction out of main memory into the CPU, and moves the program counter on so it points at the instruction after it.
Decode — the CPU's control unit examines the instruction and works out what it means: which operation to perform, and on which piece of data.
Execute — the CPU actually performs the operation. That might be a calculation (add, subtract, compare), moving data around, or reading from / writing to memory.

Then the whole thing repeats. Because the program counter was already nudged forward during the fetch, the next turn of the cycle naturally picks up the following instruction — and so the CPU marches through your program in order, one instruction at a time.

A worked walk-through

Suppose a tiny program in memory says, in order: "load the number 5", then "add 3 to it", then "store the answer". Watch how the same three steps handle each line:

Instruction 1. Fetch the "load 5" instruction from memory. Decode it: "this means put 5 into the CPU." Execute it: the value 5 is now held in the CPU.
Instruction 2. Fetch "add 3". Decode: "add 3 to the value I'm holding." Execute: 5 + 3 = 8.
Instruction 3. Fetch "store the answer". Decode: "write my value back into memory." Execute: the 8 is written to memory.

Three instructions meant the cycle turned three times — nine little steps in total — and this was a program of only three lines. A real program has millions of instructions, which is exactly why the CPU has to be so blisteringly fast.

A CPU's speed is measured by its clock speed in gigahertz (GHz). One hertz is one tick per second, and giga means a billion, so a 3\text{ GHz} processor ticks about three billion (3{,}000{,}000{,}000) times a second. Each tick pushes the fetch–decode–execute cycle along. Light itself only travels about 10 cm in the time between two ticks of a 3 GHz clock — so in a real sense the CPU is doing its work faster than light can cross the room.

It's tempting to think the CPU fetches a whole batch of instructions, then decodes them all, then executes them all. It does not. The three steps happen for every single instruction, one instruction at a time, and always in the same fixed order: fetch, then decode, then execute — then straight back to fetch for the next one. You never skip a step and you never reorder them.

Also watch the word "execute". Executing an instruction can itself read from or write to memory (for example, "store this answer back in RAM"). So memory isn't only touched during fetch — the execute step can reach into memory too.