When Intel’s opcode docs say a two-byte opcode can be three bytes long
Description
A photo meme shows a bewildered house cat standing on a wooden floor with a gray "loading" spinner GIF centered on its forehead, implying mental overload. Above the cat, a cropped page from the Intel Architecture Software Developer’s Manual is pasted. The blue-titled section reads “NOTE” followed by: “Some SSE/SSE2/SSE3 instructions have two-byte opcodes that are either 2 bytes or 3 bytes in length. Two-byte opcodes that are 3 bytes in length consist of: a mandatory prefix (F2H, F3H, or 66H), 0FH, and an opcode byte. See Table 11-3.” The specific phrase “two-byte opcodes that are either 2 bytes or 3 bytes in length” is additionally highlighted in a white callout bar, emphasizing the contradiction. The juxtaposition humorously captures a low-level programmer’s confusion when parsing x86 instruction encoding documentation, likening the reader’s brain to a buffering spinner
Comments
7Comment deleted
x86 docs: “Some two-byte opcodes are three bytes.” Nice to see the ISA using the same estimation model as our product roadmap - just add a prefix and call it scope creep
Reading Intel's opcode documentation is like being told your two-week sprint is actually three weeks, but only if you add the mandatory F2H prefix and check Table 11-3 for exceptions
x86 encoding is the original schemaless format: variable length, mandatory optional prefixes, and a spec that gaslights you - and somehow it's still backward compatible with 1978
When Intel's documentation says 'two-byte opcodes' can be 2 OR 3 bytes, you realize the real variable-length encoding was the friends we made along the way - and also why your disassembler keeps segfaulting. At least the cat's loading spinner is more honest about its confusion than the x86 instruction manual
Two-byte opcodes that are three bytes long - x86: technically correct, linguistically hostile. 66/F2/F3 + 0F + opcode, and my decoder grows a loading spinner
x86 SSE: where three prefixes solve the 'ambiguous vector op' problem by inventing four decode paths
In x86, “two-byte opcode” is a category, not a constant - add F2/F3/66 and your decoder FSM grows a state while your brain spins in busy-wait