IDK where you'd find a list sorted by length because most instructions take a ModRM byte which can encode a variable-length addressing mode.
You could sort by minimum length. Intel's vol.2 manual shows encodings, e.g. HTML extract at https://www.felixcloutier.com/x86/index.html.
http://ref.x86asm.net/coder64.html groups by 1-byte and 2-byte opcodes, and shows (in the o
column) whether that opcode takes a ModRM byte to indicate operands.
https://codegolf.stackexchange.com/questions/132981/tips-for-golfing-in-x86-x64-machine-code has a bunch of tips about things that are small in x86-64 machine code.
BTW, one of your examples is broken:
add ax, imm8
requires an operand-size prefix for 16-bit operand size in 64 or 32-bit mode. It takes at least 4 bytes to encode. (66h
+ opcode + modrm + imm8).
add ax, imm16
can use the no-modrm short form opcode for implicit AX, but needs an extra byte for the immediate.
Or did you mean add r16, r/m16
, like add ax, cx
? Yes, that's 3 bytes. But add ax, [1234 + edi + r8d*4]
is more: address-size prefix (because I didn't use 64-bit registers), SIB, disp32, and REX prefix for r8. So it's not like you can group all add ax, ...
instructions into the same size. Even if you rule out memory source operands, add ax, r8w
needs a REX prefix.
But yes, there is a 2-byte encoding for add al, imm8
, or register: 8-bit operand-size has its own opcodes, not prefixes in front of the 16/32/64-bit opcode.
And yes push
/pop
register for rax..rdi is one byte. r8..r15 need a REX prefix.
I forget what the longest instruction is without a bunch of prefixes. e.g. lock add [fs:disp32 + r10], imm32
is pretty big.
Or some SIMD instructions have a lot of mandatory prefixes, and can use a memory source operand so can have a big addressing mode.