Fetch, Decode, What???

Paying homage to the fetch-decode-execute cycle

The name of this substack may sound a bit sinister, but rest assured that nothing was killed whilst making it. It’s named after the fetch-decode-execute cycle, a key but under-appreciated component of every computer.

At the heart of a computer is a processor. Processors run programs. Programs are written in all sorts of programming languages, but before they can actually run, they get translated into something called machine language. If a program is written in an interpreted language like Python, this translation is done on the fly. In a compiled language like C++, it’s done before the program is run. Either way, the resulting machine language program is mostly a list of primitive instructions. These each do simple things like copy a value from one place to another or add two numbers together, and they correspond to the basic things that your computer’s hardware can do. For example, when the processor sees an instruction to add two numbers together, it activates the computer’s arithmetic logic unit (ALU), which contains, amongst other things, digital logic circuits for adding numbers together.

When a machine language program is run, it’s first loaded into memory somewhere, and the address where it’s been loaded gets passed to the processor, which stores it in something called the programme counter. The fetch-decode-execute cycle then fires up. This involves three stages, and you won’t be surprised to hear that they’re called fetching, decoding and executing. Fetching involves retrieving the instruction currently pointed to by the programme counter. Decoding involves working out what the instruction is asking the processor to do, and executing involves actually doing it. Once this is done, the programme counter gets incremented¹, so that it points to the next instruction in the programme, and the fetch-decode-execute cycle then repeats. It does this over and over again until the program reaches its end.

An interesting thing about the fetch-decode-execute cycle is that it has essentially remained the same since the advent of computers. Sure, there’s been a few bells and whistles added, but the basic architecture of a computer — known as the von Neumann architecture, after one of the godfathers of computing, John von Neumann — hasn’t fundamentally changed since it was introduced circa 1945. In many respects, the fetch-decode-execute cycle is like a fossil lying at the heart of every computer, not entirely unlike how the neural circuits of prehistoric organisms can still be found buried in the middle of a human brain.

Something that has changed, however, is the scale and speed of these fetch-decode-execute cycles. In modern processors, a single cycle of the fetch-decode-execute cycle takes just nanoseconds. Despite this, computers now need many processors to keep up with all the programs that are running at once, most of which the user is blissfully unaware of. Even when your computer seems to be asleep, it’s probably running programs, and this means the fetch-decode-execute cycles are constantly running — much like the engines of a giant ocean liner. Behind the calm exterior of your computer lies a hot and steamy engine room. Okay, not steamy, unless you spilt a beverage recently, but definitely hot, and it’s not unusual for some modern processors to run close to boiling point.

So, this substack is named in homage to the fetch-decode-execute cycle. May it one day rest in peace².

1. Well, occasionally it gets redirected to another section of code, or to another program, but such things are beyond the scope of this post.

2. This may happen, and perhaps sooner than we think. Neither quantum computers not analogue neuromorphic hardware have a direct analogue of the fetch-decode-execute cycle. For more about these, see: