|
Department of Computing
Course DOC 112 -- Hardware
Lecture 17: Let's Design a Real Computer (Part
1)
Duncan and Peter hardware designers completed their "real" processor design
by adding memory, and a Program-Counter (PC) to their well running manual
processor and were quite pleased showing it off to the software manager
Piotr.

We pointed out the new additions and improvements. We had to
add a Program-Counter (PC) register, also with eight bits and to
fit it into the system; therefore, we had to use an additional multiplexer.
Since we had four inputs to this new multiplexer, whose output we call the
BUS, we separated the SHIFTER from the ALU and also allowed
the A register to be directly connected to the BUS. We also
cleverly added MEMORY in the traditional, simple way when the memory
address is always kept in the MAR (Memory-Address-Register) while the
memory output is enabled at all times and reflects the contents of the memory at
the address held in the MAR. The MBR (Memory-Buffer-Register)
contains the data either for reading or writing. When reading memory, the
CLKMBR, when writing, the Memory-Write-Clock has to be generated.
We did not mention the fact that there were a few unsolved problems, like where
the new select lines SELMBR or SELBUS will come from or how the
Memory-Write-Clock is going to be generated; however, we were confident
that these problems can be solved. But, we did not get too far when .....
Piotr looked at the design in horror: No registers???
(Peter and Duncan did not want to point out the internal A and B
registers at this point). "Exactly!" Duncan and Peter said in concert. We
have fast memory so memory cycles will go like lightning, in one clock cycle, no
need for registers. This is what so revolutionary about this! "Impossible",
Piotr said, "I am sure there is something wrong with this idea, I wish I could
think what it is". It came to him slowly, but at the end it was very convincing.
For example, if one wants to sum a set of numbers, if there are no registers,
the sum has to be stored in memory as well as the numbers. Thus for each
addition more memory clock cycles are needed then if we accumulate the sum in a
register and the computer will be slower!
Duncan and Peter could have suggested the A or B register for
this purpose, but they knew better. First of all, in order to execute
instructions in a computer, they knew from experience that they needed hidden
registers which the programmer absolutely should not see (these programmers use
everything they can lay their hands on and mess up the orderly hardware
sequences!) Secondly, Piotr was very friendly with the general manager and word
came down from above not to argue. So, there they are, four general registers
called R0, R1, R2, and R3 will have to be added to
the processor; which becomes quite a conventional design now. Duncan and Peter
will have to go away, redesign their hardware if they want to keep their job.
So, Piotr simply told the hardware department what instructions he
wanted, and there could be no argument. A sad case, really.
The Software Designer Speaketh:
The instruction definitions were given to Peter and Duncan in four classes as
follows:
. .
These must operate on registers only and as shown above, the
operation code indicates one of eight different operations: MOVE, ADD,
ADD-WITH-CARRY, SUBTRACT, COMPARE, AND, OR, and EXCLUSIVE-OR (that
was lucky - our old processor could do all these operations), and the register
indicators are two bits each; thus they can select any one of the four
registers: R0, R1, R2, or R3 with bit combinations of 00, 01,
10, and 11 respectively.
. .
Class 2 instructions have a similar format with one register only and should
include the following eight operations: INCREMENT, DECREMENT, CLEAR,
COMPLEMENT, ARITHMETIC-RIGHT-SHIFT, LOGICAL-RIGHT-SHIFT, LOGICAL-LEFT-SHIFT,
ROTATE-LEFT-WITH-CARRY. (Lucky again!). Also, the subroutine RETURN
operation has the same format.
. .
These Memory-Reference instructions all must occupy two
successive eight-bit words in memory. The first word has exactly the same format
as the One-Address instructions; i.e., an operation code and a register
designator. The second one could mean one of three things (the operation code
should indicate which type is used). It may be an eight-bit data word (immediate
data), it may be an eight-bit memory address, or it can be an eight-bit indirect
memory address (the address points to memory where the address of the data
is!).
For our relief, only four such instructions are required:
LOAD, STORE, JUMP, and CALL (jump to subroutine). For JUMP
and CALL instructions the immediate mode considers the data to
be an address, the second mode an indirect address, and the third an indirect,
indirect address. The JUMP instruction does not need a register, really;
however, the CALL instruction leaves the return address in the designated
register. LOAD and STORE are reasonably standard (even hardware
designers would understand how they work).
. .
Piotr asked for as many conditional skip
instructions as possible; however, the minimum set is: SKIP (always),
SKIP-ON-CARRY=1, SKIP-ON-CARRY=0,
SKIP-IF-LAST-RESULT-IS-NEGATIVE. The skip instruction, if the condition
is true, must skip two successive memory words because usually after the skip
instruction there is a JUMP instruction which takes two memory words.
A Few Observations
The moral of this story is that there is a dividing line
between software and hardware. We can see it on the design and hear it from the
conversation. But of course, they affect each other. The situation is this:
. .
The hardware/software interface (nowadays) comes from the
requirements of the software; however, if some of the software requests would
require expensive hardware additions, they could be negotiated. In this case,
the software department was quite reasonable, and a reasonable person
(especially one who wants to keep his or her job) will not argue any
further.
The Hardware Designer Designeth
Since we have to change our design significantly by inserting
the four registers into the system, we may as well look at our old design and
see how we could improve it further. We have to provide data paths to be able to
execute the required instructions. In order to get an idea about these data
paths, we may attempt to describe the operation of the computer by
register transfer operations. These are the basic steps of the
internal operation of a computer and they usually mean in hardware terms the
setting up of the correct signals for the appropriate multiplexers and function
generators and then the generation of the appropriate clock signals which change
the contents of destination registers. A register transfer operation is
described by the following general register-transfer statement:
. .Destination-register <-- function( Source-Registers
)
For example, the add operation C = A + B may be
represented as:
. .C-Register <-- ADD( A-Register , B-Register
)
The first operations we must deal with is the
Fetch-cycle, i.e., the basic operation of the computer:
The Fetch Cycle
The fetch cycle must include the following four
register-transfer operations where F.i indicates a fetch cycle:
. .
While there are four required operations, we do not necessarily
need four clock pulses. We have to look at the operations in detail and may
discover that two of them could be done in parallel. In this case, Step-2
must wait for Step-1 since the contents of MAR is required;
however, steps 2 and 3 use entirely separate registers for both
source and destination; thus, they could be done in parallel. Step-4 must
wait until Step-2 is completed, since the contents of MBR is
required. We end up with three required steps:
. .
We learn from the fetch cycle that a data path must be supplied
from the PC to the MAR, and from the MBR to the IR.
Also, an "incrementer" is needed to increment the Program-Counter. Finally,
the memory operation MBR<--MEM[MAR] is the ordinary memory read
operation which means that the CLKMBR must be active and a data path
provided from the Memory-Data-Output lines to the MBR register.
Now, unfortunately, we have to go through all instruction types
in the same manner in order to determine all the data paths we need. This is a
painfully laborious process, but a necessary one.
Two-address instructions
The two-address instructions work quite nicely when there is a
correspondence between our ALU and the required operations: ADD, ADDC, SUB, AND,
OR, XOR. The cycles (execute) are E.1, E.2, ...
. .
The MOVE instruction can be done by:
. 
The COMPARE instruction is really a subtract operation
but without storing the result back into the destination register. We are in
luck again, there is a (B mi A) operation of the ALU that we have not
used yet; this is a good opportunity for it:
. .
Sneakily we have made the assumption that the conditions will
depend on the output of the ALU. In all the above cases the ALU
outputs indicate the results of the last operation.
One-address instructions
The one-address instructions use either the ALU or the
SHIFTER. The ALU is used for CLEAR, INC, DEC, and
COMPLEMENT (COMP),. This is the time when the setting of the ALU
output to all zeroes or all ones (-1) becomes really useful. 00000000 or
11111111 can be put into the A or the B register and data
into the other register as shown below. The shift instructions are executed by
the SHIFTER:
. 
The RETURN (from subroutine) instruction can be executed in one time
step:
.
Memory reference instructions
First, let us look at the " load immediate data"
(LOADIM) mode operations. The data for the LOAD operation is
stored in the next memory location, after the instruction. We notice that after
the FETCH cycle the PC contains the address of this memory location.
Therefore the following sequence will load the data contained in memory into the
destination register:
. 
The second incrementing of the PC is necessary (the
first increment occurred in the FETCH cycle) because the instruction which has
to be executed next is stored in the memory word after the data word.
The ordinary LOAD operation requires an address in the
second byte. The register-transfer sequence for this operations
is:
. 
Notice that this is the first time that five execution steps
were required. This is very unpleasant, really. We will try later to make the
sequences more uniform.
The ordinary STORE operation requires an address in the
second byte. The register-transfer sequence for this operations
is:
. .
The JUMP instruction with an "immediate data mode"
considers the contents of the next memory location to be an address. The
sequence is very similar to LOADIM but with a different third step:
. .
since a "jump" in the program means the changing of the program counter.
The CALL (call a procedure) instruction is similar to the JUMP
instruction but the return address must be stored in a specified register. We
can do this with the following sequence:
. .
The unusual incrementing of the PC as the first step is necessary
because the return address is one larger than the location where the address for
the CALL instruction is located. Again, there are multiple register
transfers in one clock cycle, but they look OK. to me.
Now the indirect address calculations have to be taken care of.
Actually, indirect address calculations give very little trouble to hardware
designers (as directly opposed to software writers), because after the memory
READ cycle the MBR contains the contents of the memory at the
required address. If this is data (immediate mode) then we have nothing more to
do. If this is an address then we can transfer this address to the MAR
register and do another memory READ operation In fact, instead of copying
all four instructions again, we can simply insert two or four new states into
the state transition diagram of the computer which take care of the indirect
addressing problem. This, hopefully, will become clearer when we will be
designing the new controller. We shall designate these states as I.1, I.2,
I.3, ...
. .
Finally, we are left with the skip instructions. The unconditional skip
instruction must increment the PC twice, so it will take the following
two steps:
. .
Conditional skip instructions execute exactly in the same way
using two time steps, if the conditions are satisfied; however, they do nothing
if the conditions are false. This is a control problem not a register transfer
problem and will have to be handled when the controller is designed.
Phew!! Now we have all our required register transfer
instructions, we are ready to propose the hardware paths which should be able to
execute all of them. The proposed design is shown on the next page. It is
obviously very similar to our first design, so we may be called conservatives.
On the other hand, we may be a bit careful and try something which worked
before.
Let us look at some important features of this design. The most
important data path (eight bits) of the hardware is called again the BUS
because it is the output of a four-to-one multiplexer and therefore could be a
"source" for many register-transfer operations. It may represent the shifted
A register contents (remember, one of the shift functions is "no change";
i.e. the BUS will represent the unchanged contents of the A
register in this case), the results of the ALU, the contents of the
Program-Counter, or the contents of the Memory-Buffer-Register.
Notice, that there is no direct path from the registers R0..R3 or
from the Memory-Data-Output to the BUS.
The BUS is connected to the A or B
registers (through a multiplexer), directly to registers R0..R3, to the
PC (again through a multiplexer), to the MBR (ditto), directly to
the Memory-Data-Input lines and to the MAR. Thus, it is connected
to just about everywhere.
The Carry-Input of the ALU has been given a
four-to-one multiplexer; thus a wide variety of inputs can be selected; such as
the most significant bit of the A register A7, the Carry
flip-flop output, the two constants: zero and one. This wide
variety of inputs was necessary because for the required instructions the carry
input bit must be strictly controlled.
Finally, the Controller became much more complicated. In
addition to the reset input line, the Instruction-Register bits
must be input since different instructions may require different state sequences
(like the indirect address sequence), similarly, the C bit and the
A7 bits are probably needed for conditional skip instructions. We shall
see later.
Our next task is to check our design carefully and make certain
that all our register transfer operations can be executed with it. After that,
we will have to pay attention to the controller.

|