Decode an instruction word

Paste an instruction word as hex, binary or bytes: 32 bits for ARM and RISC-V (928 encodings), or 32, 64 or 96 bits for AMDGPU (1,856 encodings, matched within the GPU generation you choose). Every field is broken out with its bit range and value.

Try 0xFFF04013 (RISC-V), 0xD65F03C0 (ARM, which is ret), or [0x01,0x05,0x0a,0x06] as AMDGPU on AMD RDNA 3, which LLVM's assembler writes for v_add_f32 v5, v1, v2. AMDGPU also takes llvm-objdump's dwords, first dword lowest: D6600005 000E0501 is v_maxmin_f16 v5.l, v1.l, v2.l, s3 on the same generation.

What it reads, and how:

  • Hex, with or without 0x: D65F03C0. Leading zeros may be left off, so 0x13 is 0x00000013; the word it read is always shown in full. Digits may be grouped with spaces or underscores (D65F 03C0). A number of more than 8 digits is one wider word, most significant digit first.
  • Binary: exactly 32, 64 or 96 digits, with or without 0b, and with spaces or underscores if you like: 0b11010110_01011111_00000011_11000000. A 0b followed by any other number of 0s and 1s is read as hex, and says so.
  • Bytes in memory order, as xxd -g1, gdb's x/4xb and LLVM's tests print them: C0 03 5F D6, 0xC0, 0x03, 0x5F, 0xD6 or [0xC0,0x03,0x5F,0xD6]. Exactly 4, 8 or 12 bytes, each two hex digits (or 0x and one or two). The first byte is the lowest (little-endian), so the last one printed is the top of the word, and these four are the word 0xD65F03C0. Any other number of bytes is refused rather than guessed at. Groups longer than two digits are digits of one number, so xxd's default groups of two bytes are not bytes here; ask xxd for -g1. A 32-bit Thumb (T32) instruction is the exception: Arm writes its first halfword first, so enter it as Arm does, such as F3BF8F2F, and not as bytes.
  • Dwords, as llvm-objdump prints AMDGPU: two or three groups of 8 hex digits, the first dword lowest.

Where the order or the base could be mistaken, a line above the results says how the input was read.

Why one word can match several instructions

A bare 32-bit word is genuinely ambiguous. The same bits mean different things in different architectures, and some encodings fix very little: RISC-V LUI pins only its 7-bit opcode, so one word in 32 really is a valid LUI. Matches are ranked by how many bits each encoding fixes, and that count is shown, so a weak match is visible as a weak match rather than presented as an answer. Narrow by architecture if you already know the target.

ARM's three instruction sets, A64, A32 and T32, share one 32-bit word space, so a word from one can match another's pattern. Each ARM entry here says which set it is, and with ARM chosen the decoder matches within one, A64 to begin with. A word that matches nothing in it is checked against the other two and reported where it does match. Checked against Arm's own encoding diagrams, with the right set chosen, 24 of 6,852 32-bit encodings decode to a different instruction, 18 of them hint instructions (PACIASP, AUTIA1716) named by the generic HINT. Under All, with no set chosen, 865 do, 584 of them Thumb words, which is why All is the weaker reading. Only a few Thumb and A32 encodings are in the set so far.

AMDGPU is decoded differently, because there the ambiguity is between GPU generations: 608 instructions change opcode from one generation to another, so the same bits name different instructions on different parts. An AMDGPU word is therefore matched only against the layouts verified for the generation you choose, and within one generation no two of them can match the same word.

What it will not do

An encoding is only listed here if its documented bit pattern rebuilds the opcode the dataset already stores for it. That check admits 2,784 of 4,134 candidate records, and the rest are left out rather than decoded on a guess: a wrong field width does not fail loudly, it returns a confident wrong answer, which in a reference is worse than returning nothing.

So no match does not mean invalid. It means the word does not match anything in the verified set. x86 is absent because its instructions are variable length rather than one 32-bit word, and PowerISA because its patterns record field values in decimal without fixed widths.

AMDGPU layouts come from AMD's machine-readable ISA specification, and each is kept only if the instruction's opcode rebuilds one of AMD's own encoding identifiers. A layout is listed for a generation only where AMD's files show the instruction encoded the same way there, which is why older generations, where many opcodes differ, have fewer. Encodings that take a literal constant or a DPP extension are not included. Register numbers are shown only for the field types whose reading was checked against LLVM's assembler; other fields show their raw value.

It was checked against LLVM's own assembler tests, which print the bytes LLVM produced for each instruction. Decoded within each test file's generation, 27,921 assembled instructions were named correctly and none wrongly, and none of 25,749 register readings contradicted the assembly. The other 134,133 lines were declined rather than guessed: 43% are longer forms of an included instruction (VOP3, DPP, SDWA or a trailing literal), 43% are instructions included only for other generations, 10% have a record but no verified layout, and 4% name an instruction by another name AMD gives it than the one its record carries, which that record's page now lists as "also written as".

The data behind this is public domain, and how its accuracy was measured is in ACCURACY.md.