x86 Instruction Set

Introduction

x86 is the instruction set of Intel’s 8086 and of every processor that has run its programs since: Intel’s and AMD’s 80286, 386, 486, Pentium, Athlon, Core, Xeon, Ryzen and EPYC, and those of VIA, Cyrix and others. It has never broken with its past. A program for the 8086 of 1978 still runs on a processor of today, and each generation added registers, instructions and wider operands on top of the last, with new prefixes to reach them. x86-64, AMD’s 64-bit extension of 2003, is the form most code uses now, on Windows, Linux and older Macs.

The instructions vary in length from 1 to 15 bytes. Programs on fileformats.org that hold x86 code, the .EXE family above all, open in the explorer, which disassembles them with its own decoder: see How the explorer disassembles a program. This reference covers every instruction that decoder knows, from the 8086 to AVX10.2 and APX: how they are encoded, the opcode maps, and each instruction by family.

History

Modes

An x86 processor runs code in one of several modes, and the same bytes decode differently in each. For a disassembler what matters is the default operand and address size, 16, 32 or 64 bits:

• Real mode is the 8086’s: an address is a segment value × 16 plus a 16-bit offset, reaching about 1 MB, with no protection. Every x86 processor starts in it. MS-DOS programs run here. Code is 16-bit.
• 16-bit protected mode came with the 80286: segment registers hold selectors into descriptor tables, with privilege levels 0 to 3. Windows 3.x programs (NE) run here. Code is 16-bit.
• 32-bit protected mode came with the 80386, with 32-bit segments and paging. Segments are usually flat, starting at 0 and covering 4 GB. 32-bit Windows (PE32), OS/2 and DOS-extender programs (LE, LX) run here. Code is 32-bit, though a protected-mode system can also run 16-bit segments and, in virtual-8086 mode, real-mode programs.
• Long mode came with x86-64. In its 64-bit sub-mode code is 64-bit: addresses are 64 bits, operands 32 bits by default, segmentation is mostly gone, and RIP-relative addressing is the norm (PE32+). Its compatibility sub-mode runs 32-bit and 16-bit protected-mode code under a 64-bit system.

System management mode, entered by an interrupt and left with RSM, runs firmware out of sight of the operating system. The Instruction encoding page gives the operand and address size rules for each mode.

Registers

Processors also have hundreds of model-specific registers (MSRs), read and written with RDMSR and WRMSR, which configure everything from system calls to performance counters.

How this reference is organised

Two pages explain how instructions are put together: the Instruction encoding, byte by byte, and the Opcode maps. The instructions themselves are on one page per family. The general-purpose ones, which every processor since the 8086 has gathered, are grouped by what they do; the extensions, by set. Each family page gives, for every mnemonic the disassembler can show, its operand forms, its encoding in Intel’s notation, what it does, and the set and processor that brought it. The explorer links each instruction it shows to its row.

How the explorer disassembles a program

Drop a program on any page of fileformats.org and the explorer opens it. Beside its structure and its resources, a program’s Code section lists its code regions (each executable section of a PE file, each code segment of an NE file, each object of an LE or LX file, the load module of an MZ file), with the address, size and mode of each. The mode comes from the file: 16-bit for MZ and for the DOS stub of a newer program, 16-bit for NE segments unless a segment is flagged as 32-bit, 16- or 32-bit for LE and LX by the object’s flags, 32-bit for PE32 and 64-bit for PE32+. Opening a region shows its disassembly.

Most disassemblers decode the first instruction, then the one after it, and so on. That shows one reading of the bytes, but x86 instructions have no fixed length or alignment, and code can jump into the middle of an instruction, which then reads as something else. Obfuscated code and copy protection do it on purpose, and data mixed into code makes a linear reading lose step. So the explorer decodes an instruction at every byte, and lays them out in columns, one row per byte:

• going through the bytes in order, each instruction goes in the lowest column that is free at its first byte;
• it holds that column for as many rows as it has bytes;
• so column 0 is the plain disassembly from the start of the region, and the other columns hold the instructions that start inside an instruction to their left. Since an instruction is at most 15 bytes long, there are never more than 15 columns.

Here are nine bytes of 32-bit code at 0x401000, a well-known trick: a short jump over one junk byte, E8, which a linear disassembler takes as the start of a call.

In the explorer, selecting an instruction shows its address and bytes, its text, the instruction set it belongs to and the processor that brought it, any problem with it (such as a LOCK prefix it cannot take), and a link to its row in this reference. For a jump or call, Go to target scrolls to the target and selects the instruction that starts there, in whichever column it is: here the mov in column 1. Enter follows a branch and Backspace goes back. Entry points, exports and imported functions are named where instructions point at them.

The decoder is fileformats.org’s own, written for the explorer from Intel’s and AMD’s manuals and the extensions’ specifications. Its text matches llvm-objdump’s Intel syntax, and it was tested against LLVM over the whole opcode space in 16-, 32- and 64-bit code; the few deliberate differences are listed on the Instruction encoding page.

Links