What Is an Opcode? Defining and Understanding Opcodes in Assembly Language

The word “opcode” gets thrown around a lot in low-level programming circles, and for a while I nodded along without a precise sense of what it actually meant versus a whole instruction. Once I sat down and disassembled a simple binary byte by byte, the picture became a lot clearer. In this post, I want to define the term properly, show exactly how opcodes are structured inside real instructions, and walk through how the CPU actually uses them.

Defining “Opcode”

An opcode (short for “operation code”) is the portion of a machine instruction that specifies which operation the CPU should perform — addition, subtraction, a memory move, a jump, and so on. It’s the verb of the instruction. Everything else in the instruction — the operands (registers, memory addresses, immediate values) — tells the CPU what to operate on; the opcode tells it what to do.

It’s important to distinguish an opcode from a full instruction:

Full instruction:  mov eax, 42
                    ^^^  ^^^  ^^
                    |    |    |
                 opcode  |  immediate operand
                      destination operand

At the machine-code (binary) level, mov eax, 42 assembles to:

B8 2A 00 00 00

Here, B8 is the opcode byte specifically meaning “move a 32-bit immediate into EAX.” The remaining four bytes are the operand (the immediate value 42, encoded little-endian). So the opcode is just one part — often just one or two bytes — of the complete instruction encoding.

Opcodes vs. Mnemonics

This distinction trips people up constantly, so let me be explicit:

• A mnemonic (like MOV, ADD, JMP) is the human-readable text you type in Assembly source code.
• An opcode is the actual numeric, binary value the assembler translates that mnemonic into.

The same mnemonic can correspond to multiple different opcodes, depending on the operand types and sizes involved — this is one of the more surprising things I learned.

mov eax, ebx        ; opcode: 89 D8   (register-to-register move)
mov eax, 42          ; opcode: B8 2A 00 00 00  (immediate-to-register move)
mov [ebx], eax        ; opcode: 89 03   (register-to-memory move)
mov al, 5              ; opcode: B0 05   (8-bit immediate move, different opcode entirely)

Every one of those is “MOV” in your source code, but the assembler picks a completely different opcode byte for each, based on operand size and addressing mode.

Anatomy of an x86 Instruction

x86 instructions are famously variable-length and can be quite complex. A full instruction can be broken into these components:

[Prefixes] [Opcode] [ModR/M] [SIB] [Displacement] [Immediate]

add eax, [ebx + ecx*4 + 8]

This single instruction’s opcode conceptually says “add a memory source to a register,” while the ModR/M and SIB bytes describe the complex addressing expression, and the displacement byte holds the +8.

Opcodes on RISC Architectures (ARM)

ARM instructions, being fixed at 32 bits (AArch32) or 32 bits (AArch64, though the encoding differs), dedicate a fixed field of bits specifically to the opcode, rather than using a variable number of leading bytes like x86.

ARM (AArch32) data-processing instruction encoding (simplified):
[Cond (4 bits)] [00] [I] [Opcode (4 bits)] [S] [Rn (4 bits)] [Rd (4 bits)] [Operand2 (12 bits)]

For example, the opcode field 0100 corresponds to ADD, while 0010 corresponds to SUB, within the data-processing instruction class. Because ARM’s opcode field is a fixed-width slice of a fixed-width instruction, decoding is simpler and faster in hardware — one of the core reasons RISC architectures can achieve high instruction throughput with simpler decode logic.

ADD R0, R1, R2      ; opcode field encodes "ADD" operation
SUB R0, R1, R2        ; opcode field encodes "SUB" operation

How the CPU Uses the Opcode: Instruction Decode

flowchart TD
    A[Fetch: read instruction bytes from memory at PC/RIP] --> B[Decode: identify opcode + operands]
    B --> C{What does opcode specify?}
    C -->|Arithmetic| D[Route operands to ALU]
    C -->|Memory access| E[Route to Load/Store Unit]
    C -->|Branch| F[Route to Branch Unit, update PC/RIP]
    D --> G[Execute]
    E --> G
    F --> G
    G --> H[Write back result to register/memory/flags]

This is a simplified view of the classic five-stage pipeline (Fetch, Decode, Execute, Memory, Writeback) found in many CPU architecture courses. The opcode, extracted during the Decode stage, is what determines which execution unit (ALU, load/store unit, branch unit, floating-point unit) the instruction gets routed to.

Opcode Tables: A Practical Example

Disassemblers and CPU manuals rely on opcode tables — reference charts mapping every possible opcode byte value to its meaning. Here’s a small excerpt of real x86 opcodes for illustration:

Notice B8–BF: that’s not eight unrelated opcodes, it’s one opcode family where the specific register (EAX through EDI) is encoded directly into the low three bits of the opcode byte itself — a neat space-saving trick from the original 8086 design that’s still visible today.

Practical Use Cases

• Reverse engineering and malware analysis: recognizing opcodes by sight (or with a disassembler) is the foundation of reading any compiled binary
• Writing a disassembler or emulator: requires building a complete opcode table/decoder for the target architecture
• Exploit development: crafting shellcode requires precise knowledge of opcode byte sequences, especially when avoiding “bad bytes” (opcodes containing null bytes or other characters a vulnerable input might filter out)
• CPU/compiler performance tuning: understanding which opcodes have longer encodings or higher latency (see Intel/AMD optimization manuals) informs manual optimization

; Example: shellcode-style exploit development cares deeply about
; exact opcode byte sequences (this is illustrative, not functional shellcode)
xor eax, eax        ; opcode 31 C0 -- avoids embedding a null byte, unlike "mov eax, 0"

Comparing CISC and RISC Opcode Design

Debugging and Analysis Tools

• objdump -d file — disassembles a binary, showing opcodes alongside mnemonics
• ndisasm file.bin (NASM’s disassembler) — useful for raw binary blobs without a container format
• GDB’s x/10i $pc — shows disassembled instructions at the current instruction pointer
• Intel/AMD’s official opcode reference tables in their Software Developer’s Manuals — the authoritative source when a disassembler’s output seems ambiguous

Common Mistakes and Misconceptions

1. Confusing “opcode” with “instruction” — the opcode is only the operation-specifying part; the full instruction includes operands too.
2. Assuming one mnemonic equals one opcode — as shown above, a single mnemonic like MOV maps to dozens of distinct opcodes depending on operand types.
3. Ignoring opcode prefixes — bytes like 0x66 (operand-size override) or 0xF2/0xF3 (used for SSE scalar instructions) change how the following opcode byte(s) should be interpreted; missing this leads to misreading disassembly.
4. Assuming ARM opcodes are always uniform across instruction sets — Thumb mode (16-bit compressed ARM instructions) uses a completely different opcode encoding scheme from standard 32-bit ARM.

Best Practices

• When reading disassembly, always check both the mnemonic and the raw opcode bytes if precision matters (e.g., for security research or writing an emulator).
• Keep a reference to the official opcode tables (Intel SDM Volume 2, or the ARM Architecture Reference Manual) handy — they’re dense but authoritative.
• When writing hand-optimized Assembly, be aware that some opcode encodings are shorter or execute faster than semantically-equivalent alternatives (e.g., XOR reg, reg to zero a register is both shorter and often faster than MOV reg, 0).

FAQs

Q: Is “opcode” the same as “instruction”? No — the opcode is the operation-specifying field within an instruction. A full instruction typically includes the opcode plus operand-specifying fields (registers, memory addressing, immediates).

Q: How many opcodes does x86 have? Counting every prefix/opcode/extension combination, x86 has an enormous number — likely well over a thousand distinct encodings when you include legacy, SSE, AVX, and other extensions.

Q: Do all architectures use fixed-length opcodes? No. RISC architectures like classic ARM and MIPS use fixed-width opcode fields within fixed-length instructions, while CISC architectures like x86 use variable-length opcodes and instructions.

Q: Can two different opcodes do the exact same thing? Sometimes — x86 in particular has a long history of “aliased” or overlapping encodings for backward compatibility (e.g., there are multiple ways to encode a NOP-equivalent instruction).

Summary and Key Takeaways

An opcode is the specific numeric field within a machine instruction that tells the CPU which operation to perform — it’s distinct from the operands, the full instruction, and the human-readable mnemonic. On CISC architectures like x86, opcodes are variable-length and richly overloaded depending on operand size and addressing mode; on RISC architectures like ARM, opcodes occupy a fixed field within a fixed-width instruction, trading some code density for dramatically simpler hardware decoding. Whether you’re reverse engineering a binary, writing a disassembler, or just trying to understand why your compiled function looks the way it does in a debugger, a solid grasp of what an opcode actually is — and isn’t — is essential.

References

• Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2 (Instruction Set Reference, includes full opcode maps) — intel.com/sdm
• AMD64 Architecture Programmer’s Manual, Volume 3 — amd.com
• ARM Architecture Reference Manual (instruction encoding chapters) — developer.arm.com
• GNU Binutils Documentation (objdump, as) — sourceware.org/binutils