Found by accident, and worse than the bug that found it. Five deliberately
broken decode cases came back green through `build.lua --test --isa x86`, while
running the same suite directly reported "253/258 PASSED, 5 FAILED".
Two independent holes, both open, so neither backstopped the other:
- the x86 test binary ended at `print_summary()` and never called `os.exit`,
so it exited 0 no matter how many cases failed;
- `do_test` looked for the words "N failed" in the output, and the x86
harness prints "N FAILED" — a lowercase-only Lua pattern, so the largest
suite in the tree was exempt from its own gate.
The exit code is the check that should have been load-bearing, so the harness
sets it. The output match stays as a backstop for a suite that forgets to, and
is now case-insensitive.
How long this has been true is not knowable from here — every x86 regression
since the pattern was written would have been reported as PASS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Riok9vMpkLmo78wsVKJHhz
`bswap` is `0F C8+rd` — the register rides in the opcode's low three bits, like
`push`/`pop`/`xchg`/`mov`, but behind an escape byte. The decoder's retry at the
+r base opcode was gated on `esc == .NONE`, so only the register-0 forms
(`0F C8` = bswap eax, `48 0F C8` = bswap rax) landed on a table entry directly;
the other seven registers came back INVALID_OPCODE. Emission was always correct
— every `bswap` this compiler has ever produced runs — but a disassembly
containing one stopped dead, which is how it surfaced: three functions in
sigil's JIT corpus disassembled to a header with no instructions under it.
The table was never the problem. BSWAP is in `tablegen/encoding_table.odin` and
in the generated decode table, exactly where it should be.
Fixing the gate meant looking at why the retry existed twice. There is a correct
+r handler further down, carrying comments that describe two bugs already found
and fixed in it — "scan ALL entries, not just the first", "scan for the sized
register rather than assuming op0" — and the copy inside the retry had received
neither, plus a third of its own. So the retry now re-runs only the LOOKUP and
falls through to the single handler, which fixes two more instruction families
that were equally undecodable:
- `xchg rAX, r` (90+rd): 0x90's run sorts NOP ahead of XCHG, and the copy
tested only the first entry for a +r form, so every `xchg rAX, r` was
rejected.
- `push bx` / `pop bx` / `mov cx, imm` (any +r under 0x66): the copy passed
`prefix` where the legacy row wants 0, since for legacy opcodes 0x66 is
operand size rather than part of the opcode's identity.
Two supporting changes. The shared handler's default answer is now the first +r
entry rather than `idx.start`, so a fall-through at 0x90 cannot answer NOP for
an `xchg`. And a base-opcode retry that does not land on a +r form is now an
error rather than a fall-through: decoding 0x0E as the 0x08 entry (OR) would be
a wrong instruction reported confidently, which is worse than an unknown byte.
Verified three ways. Every opcode in every escape map was decoded before and
after: 154 combinations changed, every one of them INVALID -> valid, and nothing
that already decoded decodes differently. All 24 BSWAP encodings and all 96
legacy +r encodings were diffed against llvm-mc's disassembly and agree
operand-for-operand. Six new decode-only cases pin the three families; five of
them fail without this change.
(Two remaining differences from llvm-mc are deliberate and documented here:
implicit accumulators are left unmaterialized so a short form re-encodes to the
short form, and `48 90` reads as `xchg rax` rather than `nop`.)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Riok9vMpkLmo78wsVKJHhz
Internal label ids are allocation-order handles: the encoder's creation
order, or the decoder's branch-DISCOVERY order (a loop's latch names the
header before an earlier forward target). Printing labels by raw id leaked
that accident into listings — label numbers appeared out of order down the
page — and the printers' `label_names: ^map[u32]string` keyed the caller's
names by those synthesized ids, which a decode consumer cannot know without
re-deriving them (the practical result: naming "label 0" could caption a
random interior branch target).
Naming is now derived at the presentation seam, shared by every ISA
(`isa.Label_Display` in isa/print.odin):
- display numbers are assigned in ASCENDING ADDRESS order, so a listing
reads L0, L1, L2 … top to bottom regardless of id allocation;
- caller names are keyed by BYTE OFFSET (`isa.Label_Names`, with a
`distinct` Label_Offset key so an id-keyed map from the old contract
fails to compile instead of silently mis-naming);
- a named offset is guaranteed a label row even when no Label_Definition
points at it — `names[0] = "factorial"` heads a function's listing.
All ten ISA printers (x86, mips, rsp, arm32, arm64, riscv, ppc, ppc_vle,
mos6502, mos65816) drop their per-printer offset_to_label maps and
write_label helpers for the shared display; each arch re-exports
Label_Offset/Label_Names beside Label_Definition. En route this fixes an
arm32/ppc/ppc_vle bug where passing ANY names map suppressed the default
L<n> label rows for unnamed labels. Decode-side id assignment is untouched:
the reloc round-trip contract (encoder ids surviving decode) and the
sparse-id padding it relies on stay exactly as they were.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Riok9vMpkLmo78wsVKJHhz
The table had the R6 unsigned mul, both muh, and mod/modu, but not the R6
SIGNED low multiply (SPECIAL funct 0x18, sa=2 → 0x98) or the R6 signed/unsigned
divide (funct 0x1A, sa=2/3 → 0x9A/0x9B). Add MUL_R6, DIV_R6, DIVU_R6 to the
Mnemonic enum + the encoding table (all SPECIAL, RD/RS/RT, mask 0xFC0007FF,
MIPS32_R6) and regenerate the tables. Verified against llvm-mc -mcpu=mips32r6
(mul/div/divu $rd,$rs,$rt). All existing mips tests pass (166/39/65/14).
The MIPS decode tables are universal — every variant (MIPS I..64/R6, the PS1
GTE, PS2 MMI/VU, PSP VFPU) shares one table. Some primary opcodes collide
across variants: most visibly 0x37 is `LD` on 64-bit MIPS but `vfim.s` on the
PSP Allegrex VFPU. The decoder took the first table match, so `LD $ra, 0($sp)`
(0xdfbf0000) mis-decoded as `vfim.s $31, 0`.
Each Decode_Entry already carries a `feature`; the decoder just ignored it.
`decode` now takes a `features: Feature_Set` (a bit_set over `Feature`),
defaulting to `FEATURES_ALL` so existing callers are unchanged, and skips an
entry whose feature isn't enabled — the first ENABLED match wins, preserving
the most-specific-mask-first order. Added `FEATURES_MIPS_III` (MIPS I/II/III +
COP0 + FPU — the VR4300 / classic 64-bit baseline) for N64/MIPS-III consumers.
decode_smoke: opcode 0x37 decodes as LD under FEATURES_MIPS_III and (still)
as the PSP VFPU entry under FEATURES_ALL. 65 decoder checks pass.
Add mem_rip_label(label_id) so a RIP-relative memory operand can
reference a label: the encoder writes a placeholder disp32 and emits a
REL32 relocation (addend 0) at the field's byte offset, mirroring the
existing .RELATIVE jump/call path. This expresses lea reg, [rip + <label>]
(position-independent data addressing).
Add op_imm_label(label_id) for movabs reg, <label>: the imm stays kind
.IMMEDIATE (form matching unchanged) but is flagged so the encoder emits
an ABS64 relocation for the imm64 instead of a literal; imm_matches_inline
forces the full IMM64 form so a small id can't collapse to mov r64, imm32.
Both labeled forms bypass the contextless recipe fast-path (which cannot
append relocations) and fall back to the interpreter. Flags reuse spare
bits in Memory (disp_is_label) and Operand_Flags (imm_is_label) -- no
struct growth. Section 11 tests cover resolved/unresolved disp, the ABS64
movabs, and an end-to-end executed lea+load.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
