CPU Architecture

The CPU architecture seems pretty conventional. I couldn’t think of anything but the plainest design here. We need an ALU and registers. We need an internal data bus (connected both to the input and output of the ALU). We need a micro-sequencer. We need a bus controller and latches for the address bus and for incoming and outgoing data.

One complication I entertained was a separate sequencer for operand addressing. That is, a separate mechanism that would read the addressing mode bits and control the sequence of possibly accessing main memory to fetch data, or the address of an operand, and then delivering the operand, however it was found, to the ALU latch. The advantage is that it would keep the complexity out of the microsequencer by removing a LOT of repeated microcode (e.g.; implementing doubly indexed mode separately for each instruction). The downside is that it would add to the complexity of the circuitry and probably slow down each instruction by two cycles. 

There’s another issue I’ll have to get to later: should the microcode for each op-code contain its own copy of the microcode to implement each addressing mode (LOTS of repeated code, and chance for a simple transcription error)? Or should the microsequencer support some kind of “sub-routine” structure, where the microcode of each op-code passes off control to a shared set of instructions that exists in only one place in the microcode to implement each of the addressing modes?

[Added Later:] The solution I’ve come up with is to add an Addressing Mode Decoder. The AMD will:

• Examine the op code bit fields to determine how many operands the instruction requires

• Examine the addressing mode bit fields for each operand bit field in turn

• Route register select bits as needed

• Look up a starting address in the MicroCode for a subroutine to fetch the operand according to the addressing mode

• Execute the MicroCode subroutine to fetch one operand, loading it into the appropriate ALU latch

• Once all operands are fetched, route the instruction field of the op code to the Instruction Decoder, which will look up the MicroCode starting address for that instruction

• Turn control over to the MicroCode Sequencer for execution

Here’s what I wound up with for the [revised] architecture:

CPU Architecture

Regarding the “Controller”:

• The Instruction Register will hold the op-code

• The Instruction Decoder will use the op-code to look up the starting address in the MicroCode ROM for the current instruction

• The Microcode block stores the microcode and also includes the program counter for the microcode memory

• The Microcode Sequencer advances the microcode program counter, handles microcode branching, handles microcode subroutines, and signals the end of an instruction to the Controller

• The Addressing Mode Controller interprets the addressing mode, including calculating indexed addresses, buffering intermediate addresses, and fetching immediate operands

• The Address Scratch is a temporary store for the address of the operand in indexed and doubly-indexed modes when I have either to do addition to an address, or when (Doubly Indirect) I have to fetch the address of the operand from memory and need a place to put it