Why are PDP-7-style microprogrammed instructions out of vogue?

Question

DEC, and at least some of their computers, especially those in the 18-bit family and 12-bit family, had these opr instructions, which contained many bitfields which encoded something like "subinstructions". Things like

• clear the accumulator
• increment the accumulator
• rotate the accumulator one place leftward
• complement the accumulator
• skip if the accumulator is zero

The nature of these simple operations is such that it's convenient to encode each one in some bit or bitfield in the instruction word, and to have the computer execute each one in a statically scheduled manner. My understanding is that's because they are often used together¹, and have simple encodings.

A later computer like the Z80 or ARM7 needs to fetch, decode and execute a separate instruction to perform each of these operations, which might not be as space or time efficient.

From what I can tell, using DEC-style microcoded instructions to perform any number of simple operations of a single register, has fallen out of vogue, or are at least not nearly as common on modern instruction set architectures. Why is this?

---

1: Not only to load small integers into the accumulator, as in cla cll cml inc rtl to set the accumulator to 6 on the PDP-8, but also for examining or manipulating bitfields, probably long division, etc.

Answer 1

[...] had these opr instructions, which contained many bitfields which encoded something like "subinstructions"[...]

What you describe is basically a (V)LIW instruction format - at least that's what it might be called today. That's what computers started out with. Separate bits for each function to be applied to the value addressed.

The DEC is somewhat of a bad example here, as its accumulator instructions are a special kind, already a bastard between clean all over LIW and dedicated encoding. The LIW aspect is used only for this accumulator subset.

Zuse's machines, like the Z22, might make a better example with their ability to have each and every instruction carry multiple operations.

A later computer like the Z80 or ARM7 needs to fetch, decode and execute a separate instruction to perform each of these operations,

Yes - and no. For one, not all possible combinations could be used together, resulting in illegal instructions. In fact, depending on the machine's construction, most of these combinations were illegal. And that's why dedicated instructions took over. Let's assume, there are like 8 different operational units in the data path. Having one bit for each in the instruction word makes easy decoding, as each would just be wired up with the enable for a single function, resulting in a fast and simple machine structure.

Of these 256 combinations (of which one would be a nop), many would not make sense - think shifting left and shifting right, or adding and subtracting at the same time. By encoding only the 20 useful combinations into a 5 bit field, 3 bits (almost half) could be freed - at the cost of an additional decoding stage.

Now, back in the old times, when machines were word-orientated (e.g. 36 bits in one word), there was much space - even resulting in unused bits. No need to add a decoding stage. Even worse, doing so would slow down the execution. Well, only a bit, but it would.

The situation changed when machines became byte-orientated and variable length instruction formats were used. Here cramping down the 8 unit lines into a single encoded 5-bit field enabled it to squeeze into a byte while leaving room for more (like a register number), without the need to fetch two bytes. Heck, it even leaves 12x8 instruction points for other encodings/irregular instructions without needing more.

which might not be as space or time efficient.

That's partially true for the time efficiency, but not space - space-wise it's an extreme saving enabling more compact code. The inner workings are (can be) still (mostly) the same, but less visible. Instead of setting a shift and an add bit, there's now a Add-And-Shift instruction.

Then again, by now encoding it into a single byte instead of a full 36 bit word, the CPU can fetch the instructions at the same speed (byte bus vs. word bus) or even 4 times the speed (word sized bus) than before. So with memory always being the slowest part, tighter encoding does not only save space, but also speeds up execution - despite the additional decoding stage.

From what I can tell, [this] has fallen out of vogue, or are at least not nearly as common on modern instruction set architectures.

Not nearly as common on the surface is maybe the point here. For one, explicit VLIW instructions are still a thing (think Itanium), but more importantly, they are always an option for internal workings of modern CPUs. Where 'traditional' code gets first decoded into sub-operations, and these later get either combined to LIW instructions again, or scheduled in parallel over different function units.

In fact, the mentioned ARM makes another good point for it to vanish. ARM had traditionally the ability to have every instruction being executed conditionally (much like Zuse did first). Cool when thinking in sequential execution, but a gigantic hurdle when it comes to modern CPUs with the ability to reorder instructions according to available data and function units. It makes rescheduling not just a hard task, but almost impossible. Even worse, ARM featured DEC-like condition handling, where each and every load did change the flags.

Bottom line: Just because something isn't (always) visible to the user-side programmer, doesn't mean it isn't there.

Answer 2

The PDP-7 was a one address machine. All instructions occupied 18 bits. The operations that manipulated the accumulator didn't reference memory, and therefore didn't need an address. But the address bits were in the instruction anyway, because all instructions were encoded in an 18 bit word. So why not use these unused bits to get more use out of the instruction bits?

Once you get to opcodes with a variable number of operand addresses, the need to economize in this way goes away.

Answer 3

Another good example of this basic architecture is the HP2100 series, which had a series of bit-field instructions that performed things like test-and-branch. They could combine up to eight instructions in some cases. This basic idea was relatively common in the few minicomputers I've looked at.

The reason they fell out of favor was that they require expansion of the microcode engine to store more state, and thus they make simple pipelining more difficult.

Consider the 6502; it ran at roughly 2x the speed of other CPUs of the era at any given clock rate because it was always fetching the next instruction while the last was completing. This was simple to implement even though the instructions took anywhere from 2 to 7 cycles to complete.

But imagine if those instructions are, effectively, macros. In that case you have to decode and the feed the individual sub-instructions into the pipeline. Not impossible, but certainly complex. So the question ultimately comes down to code density - the 6502 was designed as a microcontroller, so density was not super-important while gate count was. In a mini, which cost the equivalent of $100,000 but may have still only had 4k of memory, things look very different.

I'm not sure I would say these are VLIW. As I understand it, VLIW extracts parallelism by encoding different instructions for different functional units into a single instruction. This is not the same; these multi-instructions loops over the same functional units. It seems more in keeping with something like the 68k's microprogram, no?

Answer 4

Modern CPU architectures also need to facilitate things like memory protection, so they need to implement restrictions on what machine code can and cannot effect depending on context. You do not want normal application code to be able to mess with other code in a multiuser/multitasking environment, and you certainly do not want it to be able to crash the machine wholesale.

An architecture allowing a near arbitrary number of instructions with unintuitive effects, maybe even side effects of "illegal" instructions that arise from causing hardware-level conflicts, or even worse creating odd conditions that will cause unexpected behaviour of instructions further down the line, will make this very hard.

In a security context, even something that has the side effect of probabilistically or deterministically defining the behaviour of an undefined action can be bad news - this can facilitate unwanted monitoring of or communication with other running code....