Bxdty

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 rtl inc to set the accumulator to 3 on the PDP-8, but also for examining or manipulating bitfields, probably long division, etc.

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.

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

What you describe is basically a VLIW 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 VLIW and dedicated encoding. The VLIW aspect only used on 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 archived always at once, resulting in illegal instructions. In fact, depending on the machine's construction, most of these combinations where 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 (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 those 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 (like 36 bits in one word or so), 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 to squeeze it 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 in part 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 important, 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 CLIW 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 a DEC like condition handling, where each and every load did (could) change the flags.

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