When an actual program is run on our program, it will not flow in a straight line. Instead it will branch depending on which direction you press the controller, or any other interrupt. Because we need to be able to jump to a different path at any time we need the ability to cease one task, save its data for later, and start up another one. We will need the registers during the execution of the second task, but when it is complete we want to restore them to how we started to the first task can continue. Enter: stack. The stack got its name because it acts just like a stack of books. The last book you put on stack is the first one that you can remove. Therefore it is reffered to as a LIFO stack, for Last In First Out.
Well, we have now introduced all of the key (major) components of a microprocessor. If you recall, that leaves us with
An ALU Accumulators Flag Registers A LIFO stack An Instruction Register An Instruction Decoder A Program Counter Address and Data Registers and a Control Unit.Whoa you say--- What is the control unit? This is a state machine that controls the overall function of the processor. The instructions that come out of the control unit are generated from reading the output of the instruction decoder into an internal ROM, and then looking at a "look up table" in the ROM to output a sequence of sets of control signals. This makes up our Assembly Language. Only tasks that are programmed into our ROM can be executed on our processor. The beauty of this design style is that the programmers really only need to know a simple set of assembly calls that will be interpreted by the processor as a sequence of actions. Here's a good example -- subtraction. In order to subtract, the assembly programmer only needs to know to type "Subtr," however, internally to subtract our processor must first take the read in numbers, convert them properly to two's compliment, load number one into the Register, tell the ALU to subtract with the second number placed on the data bus. Then the address bus must be told to place the number into RAM, and then change the address bus to the display address to show the result to the user. That is quite a few steps, for only one command. Thus, we have a simple assembly language, where a single task does many steps. Assembly is not as direct a line to the CPU as many people think.
How many instructions should you have in your ROM? That brings up a big argument in the Microprocessor design rings right now-- CISC vs RISC. A Complex instruction (CISC) set makes writing programs a little easier by providing a large number of possible instructions for the programmer to use. However, a reduced instruction set (RISC) makes Microprocessor design easier by reducing the number of operations that the actual hardware needs to do. As long as sequences of the RISC set can do anything it does not have from the CISC set, no loss on functionality exists.
Where does this leave us? Well, we are going to deal with the RISC set for several reasons. One, it is faster to develop and build, two, it has proven to be just as fast as the CISC chips with less overhead, and three, most of the new video game systems are all RISC. At this point, we are actually ready to begin construction part by part of our new processor. This will be accomplished in several stages. First, we will develop the core parts that will be used in our processor, including the adder, or circuitry and other ALU components. By combining this with our other logic, we will build a brainless (no ROM) microprocessor. After this, we will put on a ROM, add more memory (enough to be mildly useful) and have built a fully functional microprocessor. However, we will be thus far leaving out some components that will lower the functionality of our processor -- namely the stack, and advanced ROM commands. This will lead us into the next installment where we add that functionality, as well as more IO and some video game console tricks. Well, don't stick around here -- Let's go make our microprocessor!
Jump Back to the Processor Design Home Page