Instruction Encoding

Instruction Stream and Record Boundary

The byte addressed by PC is byte 0 of the current instruction. Instruction decoding determines the complete encoded instruction length before operand evaluation begins.

The opcode space begins at byte 0, includes the header, and ends immediately before the first payload. Any appended EA descriptor, displacement, immediate, bitmap, or instruction-specific value is a payload. Independently selected appended units are separate payloads. Bytes after the required instruction length constitute padding.

The header is byte 0 for extrashort and short instructions and the first two bytes for medium and longer instructions. It determines the encoded instruction length and selects the opcode space before operand evaluation begins. An encoded instruction length that cannot contain the selected encoding raises TRUNCATED_INSTRUCTION before any architectural state is changed.

The required instruction length is the opcode-space length plus every required payload length. The encoded instruction length must be at least that large. For an extended instruction, every trailing byte after the required instruction length is uninterpreted padding; every byte value is valid. Padding never extends an operand, payload, descriptor, or opcode space.

Before decode validation or operand evaluation, instruction fetch and permission checks cover the complete encoded record, including padding. An inaccessible padding byte therefore reports the applicable instruction-fetch fault. An undersized record raises TRUNCATED_INSTRUCTION before architectural state changes.

Instruction Header Formats

Instruction framing is byte-oriented. Byte 0 identifies extrashort and short instructions. Extended instructions use byte 0 and byte 1: byte 0 supplies the framing and encoded length, while the remaining bits of those bytes carry the first fixed bits that select the opcode and the first operand-selector fields.

For an extended instruction, byte0[5:2] is L and the encoded instruction length is \(3+L\) bytes. The opcode space contains fixed bits that select the opcode and operand-selector fields; it occupies three bytes for medium instructions, four bytes for long instructions, five bytes for extralong instructions, and six bytes for xxlong instructions. An extended instruction is invalid when its encoded length is shorter than the opcode space selected by its header.

LEN n, <instruction> requests an encoded extended instruction length of n bytes, where 3 <= n <= 18. The requested length must cover the required instruction length. Without LEN, the assembler emits that required length. It fills requested trailing padding with zero. A disassembler emits LEN n, when the encoded instruction length exceeds the required instruction length so reassembly preserves the length; padding byte values are not preserved. Extrashort and short encodings retain their fixed lengths.

Instruction Start Byte Formats

Figure [fig:instruction-header-byte-formats] is read from high to low bit. enc. denotes instruction-specific bits within the opcode space: fixed opcode bits and operand-selector fields. In byte 0, bit 7 selects extrashort framing; bits 7..6 select short (10) or extended (11) framing. For extended instructions, EXTENDED_HEADER.L directly encodes the encoded instruction length as \(3+L\) bytes.

The extended class selector is byte0[1:0] followed by byte1[7:4]. Values 0 through 59 select a medium opcode space, and values 60 through 62 select a long opcode space. When the selector is 63, byte1[3:2] completes an eight-bit class prefix: 1111110x selects extralong and 11111111 selects xxlong. The 11111110 prefix retains extralong framing but is reserved for custom extensions and is not assigned by the standard ISA.

Encoded Instruction Length Truth Table

Byte 0 Pattern	Byte 1 Pattern	Bytes
0xxxxxxx	–	1
10xxxxxx	xxxxxxxx	2
110000xx	xxxxxxxx	3
110001xx	xxxxxxxx	4
110010xx	xxxxxxxx	5
110011xx	xxxxxxxx	6
110100xx	xxxxxxxx	7
110101xx	xxxxxxxx	8
110110xx	xxxxxxxx	9
110111xx	xxxxxxxx	10
111000xx	xxxxxxxx	11
111001xx	xxxxxxxx	12
111010xx	xxxxxxxx	13
111011xx	xxxxxxxx	14
111100xx	xxxxxxxx	15
111101xx	xxxxxxxx	16
111110xx	xxxxxxxx	17
111111xx	xxxxxxxx	18

Opcode-Space Class Summary

Class	Opcode-Space Bytes	Header Selector	Minimum Bytes	Validity
extrashort	byte 0	0xxxxxxx	1	exactly 1 byte
short	bytes 0–1	10xxxxxx	2	exactly 2 bytes
medium	bytes 0–2	extended selector 0–59	3	encoded length at least 3 bytes
long	bytes 0–3	extended selector 60–62	4	encoded length at least 4 bytes
extralong	bytes 0–4	extended selector 63, prefix 1111110x	5	encoded length at least 5 bytes
xxlong	bytes 0–5	all-one eight-bit prefix	6	encoded length at least 6 bytes

Unavailable and Unassigned Encodings

An unassigned encoding or an encoding marked reserved does not define alternative architectural behavior. Instruction opcodes, extension opcodes, and effective-address forms with that designation, together with encodings for an optional instruction group whose CPUID feature bit is clear, raise UNAVAILABLE_INSTRUCTION_EXTENSION during decode.

Instruction Payload Ordering

The instruction header is byte 0 for extrashort and short instructions and the first two bytes for medium and longer instructions. The opcode space may continue after the header. If a descriptor, immediate, displacement, or bitmap follows the opcode space, each independently determined unit is a separate payload, and the payloads occupy increasing addresses in decode order. All extended EA descriptors precede every other payload, and multiple extended EA descriptors appear in declared instruction operand order. The remaining payloads then appear in declared instruction operand order. An extended EA descriptor and a following displacement are therefore separate payloads, and the displacement follows every extended EA descriptor in the instruction.

Signed displacement and immediate payloads use two's-complement representation at their declared width before any sign extension performed by the consuming instruction or effective-address encoding.

Immediate Operand Interpretation

Operand	Bits	Value	Range	Extension	Applies When
PAIRn	3	identifier	0..7	none	PUSHP/POPP canonical register-pair selector
pt_level	3	enumeration	1..4	none	PTQUERY page-table level selector
flags_bitmap	4	bitmap	0..15	none	SETF integer FLAGS image
imm6	6	unsigned	0..63	zero-extend	integer encodings with an explicit B/W/L/Q operation size
imm7	7	unsigned	0..127	zero-extend	EXTRACT register-pair encodings

PUSHP and POPP interpret their 3-bit operand as a canonical register-pair index, so every encoding from 0..7 is valid. PTQUERY uses a 3-bit page-table level; assigned levels are 1..4, while encodings 0 and 5..7 are reserved. SETF interprets its 4-bit bitmap range 0..15 as a complete FLAGS image: bit 3 writes FLAGS.Z, bit 2 writes FLAGS.N, bit 1 writes FLAGS.C, and bit 0 writes FLAGS.V. Each one writes the corresponding flag to one, and each zero writes it to zero.

SETF Flag Bitmap

A 6-bit imm6 value in 0..63 is zero-extended to the selected operation size before use when that size is wider than 6 bits. EXTRACT uses the 7-bit imm7 range 0..127 as the offset into its concatenated register pair.

Representative Encodings

The following opcode space byte layouts show framing, encoded length, fixed opcode bits, and operand-selector fields in instruction-stream order. Each row is read from bit 7 to bit 0.

Short Encoding for MOV.X(z:L/Q) Rn(s), Rn(d)

Medium Encoding for MOV.X(z:B/W/L/Q) Rn(s), <ea>(e)

Long Encoding for ADC.X(z:B/W/L/Q) Rn(s), <ea>(e)

In these examples, z selects the operation size, s and d select integer registers, and e selects an effective-address form. A field may cross a byte boundary, as s does in the medium and long examples.