> I was curious why 21 bits? I would have expected this would have been a multiple or instruction size or perhaps also 16 bits. Or is there really no correlation between size of an instruction and it's underlying micro-ops?
From the US4449184 patent [1], the microcode format was:
5 bits - S (data source)
5 bits - D (data destination)
2 bits - TYP (microinstruction type, e.g. 1 for an ALU op)
5 bits - A (opcode)
3 bits - B (varies by instruction type)
1 bits - F (whether to update the status flags)
In the second figure of the patent, you can clearly see the source/dest controls (each 5 bits) leaving the microcode ("STG 2 ARRAY") and labelled "S-BUS" and "D-BUS". There's another 5 bits (labelled "A-BUS") going to the ALU opcode decoder, 2 bits going to the "CR INC" regsiter (for jumping/branching within the microcode) and a couple of other miscellaneous bits that seem to influence the decoding of further instruction bytes.
So why 21 bits? That's exactly how many bits were needed to encode all of the various microinstruction fields, no more and no less. Since the ROM is internal to the CPU, there's no need to fit the instructions into an integral number of bytes.
The thing that puzzles me is there are 6 values for TYP (patent col 24 line 63) but only two bits instead of three. So they must be doing something tricky like borrowing a bit from A or B.
Also, kiwidrew, if you're examining this closely, the 2 bits go from CR INC to the MUX, not to CR INC. What they are doing is generating a microcode start address from the instruction, and assigning 16 micro-instructions to that instruction by default. CR INC is a counter that steps through these micro-instructions. The idea is that most instruction (< 16 micro-instructions) won't need to do any jumps. A tricky part is that 2 bits of CR INC are part of the microcode row address, while the other 2 bits select 1/4 of the row. In other words, there are four 21-bit micro-instructions in each physical 84-bit row, so the ROM array isn't excessively tall and skinny.
Ah ha, thanks for explaining CR INC, that makes sense now. I have only been looking at the diagrams in the patent.
The patent does enumerate (col 25 line 15) the TYP values: 0, 1, 4, 5, and 6. (The microcode listings also sometimes use a value of 7 for TYP.) So this would suggest that types 0 [conditional jump] and 1 [ALU operation] use a full 5-bit A field (to set the ALU opcode) while types 4-7 use a different format for the A and B fields. The MSB of TYP would select between the two formats, and this would explain the absence of a type 2 or type 3 instruction.
From the US4449184 patent [1], the microcode format was:
In the second figure of the patent, you can clearly see the source/dest controls (each 5 bits) leaving the microcode ("STG 2 ARRAY") and labelled "S-BUS" and "D-BUS". There's another 5 bits (labelled "A-BUS") going to the ALU opcode decoder, 2 bits going to the "CR INC" regsiter (for jumping/branching within the microcode) and a couple of other miscellaneous bits that seem to influence the decoding of further instruction bytes.So why 21 bits? That's exactly how many bits were needed to encode all of the various microinstruction fields, no more and no less. Since the ROM is internal to the CPU, there's no need to fit the instructions into an integral number of bytes.
[1] https://patents.google.com/patent/US4449184