Understanding the Microprocessor

Part I: Basic Computing Concepts

Refining the model

If we were to animate the diagram at the beginning of the article, you'd first see the code stream flow into the right-hand port of the ALU. Once it had entered the unit, the data stream would follow it as bits of data began to trickle in from storage in accordance with the demands of the instructions in the code stream. Last of all, the results stream would emerge from the bottom of the unit and make its way back to storage. What I'll do in this section is zoom in on the relationship between the code, data and results streams.

For a computer to add two numbers, it must go through the following sequence of steps:

Obtain the two numbers to be added from storage.

Add the numbers.

Place the results back into storage.

Since the numbers must first be fetched from storage before they can be added, we want our storage space to be as fast as possible so that the operation can be carried out quickly. Since the ALU is the part of the processor that does the actual addition, we'd like to place the storage as close to it as possible so that the operands can be read almost instantaneously. However, practical considerations, such as a modern CPU's limited die space, constrain the size of the storage area that we can stick next to the ALU. This means that in real life, most computers have a relatively small number of very fast storage locations attached to the ALU. These storage locations are called registers, and the first x86 computers only had 8 of them to work with. These registers store only a small subset of the data that the computer is currently working with. (We'll talk about where the rest of that data lives, shortly.)

Filling out our previous, 3-step description of what goes on when a computer adds two numbers, we can replace it with the following sequence of steps.

Obtain the two numbers to be added (or, the "operands") from two registers.

Add the numbers.

Place the results back in a register.

To take a more concrete example, let's take the case of a simple computer with only 4 registers, labeled A, B, C, and D. Suppose each of these registers contains an integer, and we want to add the contents of two registers together and overwrite the contents of one of those registers with the
resulting sum, as in the following operation:

Code

Comments

A = A + B

Add the contents of registers A and B and place the result in A, overwriting whatever's there.

The ALU in our simple computer would perform the following series of steps:

Read the contents of registers A and B.

Add the contents of A and B.

Write the result back to register A.

This is quite simple, but that's how it really works. In fact, you should stop and take a quick look at the
P4's
pipeline, because it actually has separate stages for each of these
operations. Stages 15 and 16 of the P4's pipeline are dedicated to loading the
register files with data and to the ALU's reading of the register files. Stage
16 is the actual execute stage. (Don't worry if you don't know what a pipeline
is, because that's a topic for a future article.)

So the P4's ALU reads two operands from the integer register file, adds them together and writes the sum back to the integer register file. If we were to stop our discussion right here, you'd already understand the core stages of the P4's main integer pipeline--all those other stages are either just preparation to get to this point or they're clean-up work after it.

Putting some pieces together

If you've been reading closely, you might have noticed that there's a homology between the three steps of the read->calculate->write structure that I've been repeatedly illustrating and the three bullet points in our initial "file clerk" definition of a computer. Here's the parallel laid out explicitly:

A computer is a device that shuffles numbers around from place to place, reading, writing, erasing, and rewriting different numbers in different locations according to

a set of inputs, [read]

a fixed set of rules for processing those inputs, [calculate]

and the prior history of all the inputs that the computer has seen since it was last reset,
[write]

until a predefined set of criteria are met which cause the computer to halt.

That, in a nutshell, sums up what a computer does. And in fact, that's all that it does. Whether you're playing a game or listening to music, everything that's going on under the computer's hood fits into the model above.

All of this is fairly simple so far, and I've even been a bit repetitive with the explanations. This was done in order to drive home the basic read->calculate->write structure of all computer operations. It's important to grasp this structure in its simplicity, because as we increase our computing model's level of complexity we'll see this structure repeated at every level.