This is an HTML-ized version of the opcode map for the 8086 processor. It is based on the opcode map from Appendix A of Volume 2 of the Intel Architecture Software Developer's Manual. A plain-text version - easily parsable by software - is also available.

This map was constructed by taking a map for a more recent x86 processor and removing information irrelevant to the (much earlier) 8086 processor. I wanted as simple a map as possible, and, to that end, this map contains some lacunae:

• * Opcodes D8 through DF - the co-processor escape opcodes - are here treated as undefined opcodes. I wanted to focus on integer opcodes in this map, as floating-point would be exceedingly rare in production 8086 code.
• * Opcode 0F - "POP CS" on the 8086, and the first byte in multi-byte opcodes on later processors - is also treated as an undefined opcode. I wouldn't expect to see this in 8086 code (as the "POP CS" instruction is particularly useless) and wanted to treat its appearance as an error condition.
• * Opcodes C6, C7, and 8F require that the reg bits of the ModR/M byte which follows them be equal to zero. Other values are illegal. This restriction is not shared with other opcodes with "E"-addressed arguments, and not reflected in the map.
• * Arguments are not given for a large number of opcodes (e.g. A4 through A7, 9C, 9D) which correspond to instructions which take no arguments when written as assembly code (e.g. MOVSB, MOVSW, CMPSB, CMPSW, PUSHF, POPF). I want to use this map to build a disassembler, not a simulated processor, and the extra arguments would only be burdensome.

In addition to the information that was removed, this map contains two known errors. These were added intentionally so that the results of disassembly based upon this map would mirror the output of DOS DEBUG:

• * Opcode 84 should have arguments of Eb, Gb - not Gb, Eb. This distinction only affects (dis)assembly, since the order of operands is irrelevant to TEST's function. Nevertheless, DOS DEBUG has it backwards, and I duplicate the error here.
• * Opcode 85 should have arguments of Ev, Gv - not Gv, Ev. All the preceeding remarks about opcode 84 apply equally here.

To use the map, find the cell in the row labelled with the opcode's most significant 4 bits, and the column labelled with the opcode's least significant 4 bits. (The map is split in half; columns 0-7 appear in the first part, while columns 8-F appear in the second.) For instance, opcode 23 appears in the 3rd row, 4th column of the first part of the map (AND Gv, Ev). Opcode 4E appears in the 5th row, 7th column of the second part of the map (DEC SI).

Arguments are either a pair of letters - the first in upper case, the second in lower case - or a special symbol. An upper case/lower case pair can be interpreted by looking up the upper case letter in the "Argument Addressing Codes" table, and the lower case letter in the "Argument Operand Codes" table. Other special symbols can be looked up in the "Special Argument Codes" table.

Continuing the earlier example, opcode 23 resolves to an AND Gv, Ev instruction. Both arguments are upper case/lower case pairs. G represents a general-purpose register selected by the reg bits of a ModR/M byte following the opcode byte. E represents a memory location or general-purpose register selected by the mod and r/m bits of a ModR/M byte following the opcode byte. Both operands are of type "v", so both are WORDs. Opcode 23, therefore, takes the logical AND of a WORD from a 16-bit register or memory location with the WORD from a 16-bit register, and stores the result to the latter register. The particular register(s) and/or memory location involved can be determined by examining the ModR/M byte following the opcode, and consulting page 2-5 of the Instruction Set Reference.

Opcode 4E, on the other hand, resolves to a DEC SI instruction. The SI argument is not an upper case/lower case pair, so we check the special code table. SI turns out to represent (as one might expect) the 16-bit SI register, so opcode 4E simply decrements this register by 1. (Yes, with nearly 30 years hindsight, there probably shouldn't be an entire opcode devoted to this operation.)

The one remaining complexity involves "group" opcodes, such as 80. These opcodes perform different operations depending upon the value of the reg bits in the ModR/M byte following the opcode byte. For example, opcode 80 followed by a ModR/M byte with a reg of 4 is an AND Eb, Ib instruction, while that same opcode followed by a ModR/M byte with a reg of 7 is a CMP Eb, Ib instruction.

To disassemble "group" opcodes, consult the "Opcode Extensions" table for any entry in the opcode map with a mneumonic of the form GRP#. Find the entry in the row labelled with the mneumonic and the column labeled with the value of the reg field of the ModR/M byte following the opcode byte. Note that arguments may be specified in both the opcode map and the opcode extensions table (e.g. for opcode F6, reg 0); if this occurs, the entries in the extensions table take precedence. Normally, however, the arguments from the opcode map are used.

As far as I know, this opcode map is, modulo the lacunae and errata mentioned above, correct. I've used it to implement a full 8086 integer disassembler, the results of which agree with DOS DEBUG. However, if you see something that doesn't look right, please contact me. If you're interested in reading more about the disassembler, the following posts might be worth a look:

• Disassembly by hand
• Building the map
• 319 lines of Python