Instruction processing in the AGC is quite complicated. It had a 15-bit word length, with 3 bits used for the opcode and 12 bits used for the address. This gives us 23 = 8 instructions, and allows us to address 212 = 4,096 words of memory, right?
Nope. In reality, the computer supported 34 instructions, and had 2,048 words of erasable memory and 36,864 words of fixed memory. The memory addressing was handled by a somewhat complex banking scheme, which I’ll cover in a later post. But what about the instructions?
R-700 boils it all down into one somewhat confusing diagram in figure 3-6:
Bits 13, 14, and 15 make up the 3 base opcode bits. An extra internal bit could be set by executing the EXTEND instruction. The extend bit acts essentially as just a fourth opcode bit — when it’s set, an entirely different set of instructions is selected from. These are called the “extracode instructions”. At the end of every instruction (except INDEX), the extend bit is reset back to zero. (As a result of this behavior, interrupts are inhibited while the extend bit is set).
EXTEND itself is actually not one of the 8 base instructions either; it’s in a different class known as “implied address instructions”. The premise behind implied address codes is that not all addresses make sense with all opcodes. The first 7 addresses in erasable memory aren’t actually used for RAM; the AGC maps internal registers to these addresses. I’ll go into more details in the next installment, but for now I’ll just say that not all of them are 15 bits long. The computer normally has no issue executing instructions directly out of registers in the memory map (to the instruction loader, they appear to just be in memory, after all), but this really only works for registers that are the same size as an instruction word. EXTEND, therefore, is actually assembled as “TC 00006”, transfer control to memory location 6, which contains one of these stubby registers. Knowing that this request can’t be right, the computer instead executes EXTEND.
There are other instruction/memory combinations that don’t make sense. Recall that the AGC has two types of memory: erasable (which can be modified) and fixed (which can’t). Instructions that modify memory, therefore, don’t make any sense when supplied with fixed memory addresses. Look at how the address for an instruction is encoded in figure 3-6: erasable memory is accessed only when bits 11 and 12 of the word are 0. Again, we can use this to our advantage: if bits 13-15 (and the extend bit) indicate an erasable instruction, we know bits 11 and 12 won’t be in use for the address, so we can use them as more instruction bits. In this situation, these bits are called the “quarter code”, because they select from 4 possible instructions for each erasable “general” opcode.
We can take this concept even further when dealing with I/O instructions. I/O is done through “channels” that don’t exist in the main address space (again, more on this later). There’s only 63 of these, which leaves plenty more room in the instruction word for encoding the instruction. In practice, only bit 10 of the instruction was used for this. Figure 3-6 calls this a “channel” instruction.
Now, onto decoding.
While an instruction is executing, the instruction to be executed next is loaded into the internal B register. Upon instruction completion, the new instruction is transferred out of the B register and split into two separate registers — the S register, which receives bits 1 through 12, and the SQ register, which receives bits 10 through 15, which is enough to decode the instruction using all of the above rules.
With all of that background, here’s a top-level look at Module A3, the SQ Register and Decoder.
Page 1 contains the SQ register itself, the extend bit, and first-stage decoding logic that maps the three base opcode bits into eight signals representing the eight possible combinations, and similar logic for the two quarter code bits. It also has a bit of interrupt inhibition logic that interacts with the extend bit stuff.
Page 2 contains the next step of instruction decoding. This is where instruction selection actually happens. Here the eight opcode signals, four quarter code signals, extend bit, and SQ bit 10 are combined to create many more signals, essentially one for each instruction. Output signals from here are named after the instructions themselves.
The next step in the instruction processing chain is Module A4, the Stage Branch Decoding Module. The first page contains the stage and branch registers themselves:
The stage registers STG1, STG2, and STG3 are used to select which phase of an instruction is being executed for multi-MCT instructions. The branch registers are used to handle conditions for branching instructions.
Page 2 of the Stage Branch Decoding module appears to combine the outputs of these registers with the instruction selection logic of the SQ Register and Decoder module in a manner similar to the cross point generators.
When all is said and done, we’ve now selected the subsequence of control pulses to be executed during the current MCT.
The last step is to combine our instruction selection with the time pulse signals T01,T02,…,T12 from the Timer module to generate the actual control pulses. These are basic microinstructions that mostly interact with the core registers — things like “WA” (Write the value on the write bus to the A register) or “NISQ” (load a New Instruction into the SQ register). This work is done in Module A5, Cross Point Generator NQI, and Module A6, Cross Point Generator II. These modules implement a “control pulse matrix”, which outputs the logical product of the time pulses and subsequence selectors.
R-393 Figure 2-3 contains a pretty good diagram of what all of this looks like in a block diagram:
Note that this is for the Block I AGC, so some details are not quite the same as what I discussed above, but it’s pretty close.
That’s it for now. Next up in the tour are the central registers!