8086 Opcode Redundancies

Looking over the opcode map for the 8086 processor, I was struck by the seemingly large number of redundant opcodes. I decided to determine exactly how many were redundant, and I was surprised to find that just over 30% of the available 1-byte opcode space was assigned to redundant, short-form opcodes. While I’m sure Intel had good reasons to burn these opcodes at the time (most likely related to code size or performance), the scale of the waste gives some indication of just how surprised Intel must have been to see this instruction set architecture live on for 31 years (and counting).

Redundancy

It can be a little tricky to define a “redundant” opcode. In principle, for instance, one can do without almost any particular opcode, given that there is usually some combination of others which can be used in its place. Therefore, I define an opcode as redundant iff:

• Any instruction containing that opcode can be replaced with some single alternate instruction containing a different opcode. An opcode is not redundant if instructions containing it can only be replaced with multi-instruction sequences. The replacement instruction may be longer than the original instruction.
• The operand size(s) of the replacement instruction are the same as those of the original instruction. For instance, this rule means that EB is not redundant with E9; even though any short jump can be replaced with a near jump, the operand sizes are different.
• The opcode is not one of the “special cases” 90, C3, CB, or CC, all of which seem (to me) to have good reason to have special short forms distinct from their more verbose cousins 87, C2, CA, and CD.

The List

Here are all the redundant opcodes in the 8086 instruction set, and alternate ways to encode instructions containing them:

Counts

There are 78 redundant opcodes, as I have defined them. They occupy 30% of the available 1-byte opcode space, and they account for 33% of the opcodes defined when the 8086 was launched. If you relax my latter two constraints you could probably find another half-dozen or so redundant opcodes. Of course, one could also begin to argue about the wisdom of including support for certain instructions (e.g. the BCD stuff, or string operations).

I think it’s pretty clear than this architecture was never intended to survive so long. It’s a testament to everyone involved that it has, given that the legacy of its early days has never been particularly helpful, from a programmer’s standpoint.