Two weeks ago, I began a series of posts on computer architecture for the layman with an introduction to memory hierarchies. Last week we covered instruction pipelining, and today, I’d like to continue this “Explain Like I’m 5″ series with a glimpse at the instruction set architectures used in modern processors.

Throughout these posts, I’ll be using one central analogy in my attempt to bring everything together: the main assembly line in a car manufacturing plant, which is analogous to the processor (or CPU) that lies within a larger computer.

So, building upon our fictional auto plant in Analogy Land, this week’s post will cover instruction sets, which act as a communication interface for the assembly line. You could think of them as the way a plant manager or car designer would write instructions for the workers to understand and follow as they build a certain model of car. At this point, the only prerequisite to understanding this post is that you’ve read the previous ones and don’t believe me to be a clueless impostor.

Last Time, On The Internet

It’s time for a quick recap of last week’s coverage. Recall that we’re trying to optimize the workings of an auto plant’s assembly line. To this end, we’ve divided the process of assembly into five stages, one for each worker, such that they can run in parallel and improve the system’s overall efficiency. This is called pipelining and it hinges on the idea that each worker has only a single, simple task to do at any given time, before starting the next one. Since these tasks are short and simple, they can (and should) be executed as quickly as possible. The best to avoid the whole plant becoming a hectic mess is to have clear and explicit instructions detailing exactly what needs to be done at each moment. In fact, that was the very first stage of the pipeline we covered last time, the Instruction Fetch or IF. The worker filling this role of instruction fetcher is therefore in charge of maintaining the master list of instructions and making sure all the steps in the construction are done in the right order.

Awaiting Further Instructions

“Fair enough,” you might say, “so there’s some car designer somewhere that writes a list of instructions on how to build a car and then faxes the plant a copy and everything else is gravy.” Well, sure, that’s about right, but that also glosses over a couple of things…

First is the fact that the head office writing up these instructions is in Germany, but our particular plant is in China, as stereotypes would allow. Which means it needs to be translated into arguably the hardest language to learn, but that’s a story about Assembly Programming for another time.

Second, and far more importantly, is the fact that we don`t know what the workers in our particular plant are capable of. I mean, sure, we know that they have the general skill set and tools necessary to build a car, but are they capable of understanding and completing each and every instruction we send them? The workers have different things to do depending on the current instruction, and so we want them to have enough training that they know what to do in each case. We don’t want to have to micromanage each employee at each instruction, we just want to tell everyone in the plant to “mount the engine” and then assume they know exactly what to do.

This makes the job of the designer writing the instructions much easier, since he can just write a single high-level command and then know that it will be carried out correctly. Even better, he doesn’t really need to know anything about this specific auto plant, only that they are capable of carrying out such a command. That means that so long as all the different auto plants all over the world have the same capabilities, we don’t really care how they are executed internally! Thus, that means we can send the same exact instruction manual to every plant all over China, and even if the exact internal implementation of each plant is slightly different (for example, one of the workers is a robot), the end result (the cars they produce) will be the same.

What we’re describing here is the idea of an abstraction. In other words, the auto plant, to the designer, is just a black box that when you give it instructions (and parts) will produce cars. The workers of the plant simply have to tell the head office what instructions they are capable of, and this forms their interface, which is the only thing visible to the designer. This set of instructions they are capable of carrying out is aptly called their instruction set, which is all of the functionality that they provide. It’s effectively the basic building blocks, since you can do much more complex things by simply combining multiple commands in clever ways.

A Simple Example

So then, what sort of instruction set does a typical auto plant provide? Well, there are many ways to get fancy and add extra functionality to our auto plant, but let’s stick to just the basics, which are sufficient to get a car built from a heap of parts, and that’s all that really matters. The easiest way to think of all the necessary instructions an auto plant needs to provide is to think of all of the things that can go wrong during the assembly:

1. Load: If we need a part that isn’t currently on the shelf, we need to run to the backroom and get it.
2. Store: If the shelf is full, we need to make room, so we should pick a piece that won’t be needed for a while and go store it in the backroom.
3. Add: The easy one, the simple act of attaching a piece to another, and then bringing it back to the shelf since we’ll likely add to it again soon.
4. Compare: Sometimes we need to check if a piece is going to fit before installing it, and we’ll have to follow alternate instructions if it doesn’t.
5. Branch: When we need to follow alternate instructions, either due to an incorrect piece as above, or because we need to repeat a certain step several times, we simply jump to the new location in the instructions and resume work from there.

IRL

Just as the car designer writes instructions for the workers to follow, programmers write code (instructions) for the computers (the auto plant and its workers) to follow:

1. Load: Load some data from the RAM into a register.
2. Store: Free up a register by storing its data back into RAM.
3. Add: Add two pieces of data together. This could also be other common math operations like subtract, multiply, divide, shift, etc.
4. Compare: Check to see if one piece of data is bigger or smaller than another.
5. Branch: Jump to a new location in the code and continue executing from there. There are also conditional branches that will jump only if a certain condition is met.

And even though it all looks incredibly simple, this forms the very foundation of all computing. Of course, in reality there are a few more instructions available to us, just take a look at this relatively simple MIPS instruction set. But the concept is still broken down into three categories: data transfer (load and store), arithmetic and logic (add and compare), and control flow (branch). And these basic math operations allows us to do literally anything, just look at your smartphone.

This is also why, if you’ve been following the growing debate on software patents, our industry is increasingly averse to the idea that “basic math” can be patented. Because all software boils down to these basic math operations, it’s not a question that’s even open to debate. Granted, this basic math is buried under layers upon layers of advanced tools that we’ve built up over the years to make our jobs easier, but that’s what makes it all the more amazing. We’ve gone from punching holes into paper cards just to add two number together, to creating websites in a few hours (just look at this one)!

Onwards

Anyways, enough teary-eyed reminiscing, let’s not get ahead of ourselves. The instruction sets we’ve covered today give a programmer (car designer) a glimpse into what the computer (auto plant) is capable of, and that’s a great start. But it’s still a bloody pain to have to write out exact and explicit instructions in machine code (Chinese (sorry I don’t mean it that way)). So, the next thing I want to cover is the first tool on our way to advanced programming languages, Assembly, a low level-programming language that is almost machine code, but allows you to write in your native language (English or so) by translating it afterwards.

Until next time!