An instruction carried four operands. The coprocessor transfers need
six -- `mcr p15, #0, r0, c0, c0, #0` -- and dropping the tail is not
merely printing short: an opc2 that is not zero encoded as zero, which
is a different instruction. Six operands do not fit alongside the rest
in 64 bytes, since Operand is 11 and Memory cannot go below 8, so
Instruction is 128 now and straddles two cache lines rather than one.
With room for them, the block itself turns out to have been wrong
throughout. CDP, MCR and MRC took CRd from bits 19:16, which is CRn;
CRd is 15:12. MCR and MRC read a four-bit opc1 where theirs is the
three bits at 23:21. Neither they nor CDP read opc2 at all. MCRR and
MRRC dropped CRm.
LDC and STC were worse: they took CRd from the base register's field,
read the offset with the halfword-load encoding rather than as an imm8
counting words, and their base pattern named P=0 W=0, which is the
unindexed form whose syntax is `{option}` and not what they printed.
They now have the offset, pre-indexed and post-indexed forms, with U
left out of the mask because it is the offset's sign and belongs to the
memory operand. The N bit asks the coprocessor for the long transfer
and the syntax spells that as an L, so LDCL, STCL, LDC2L and STC2L are
mnemonics of their own.
None of this is reachable from the table sweep, which decodes each
form's canonical word with every variable field zero -- for these that
means p0, which ARMv8 reserves and no assembler will take. So twelve
hand-picked words go in the pipeline test instead, checked against the
text an assembler accepts for them, including a p15 system-register
read.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
NEON reuses one operand shape across every element width, so `vadd.i8` and
`vadd.f32` are both DPR,DPR,DPR and only the type separates their encodings.
The type existed nowhere in the data: the encoder could reach the first form
of a shape and no other, and the printer reconstructed a suffix from the bit
pattern at print time. 489 of 1680 forms -- 29% of the table -- were
unreachable, and `inst_vadd(d0,d1,d2)` could only ever produce VFP vadd.f64.
Add `Data_Type` and carry `dt: [2]Data_Type` on Instruction, Encoding and
Decode_Entry. Two slots because the convert family names both ends
(`vcvt.s32.f32`); everything else leaves the second .NONE. In A64 the
arrangement belongs to each operand (`add v0.4s, v1.4s, v2.4s`); in A32 it
belongs to the instruction, which is why it goes here and not on Operand.
Instruction does not grow: it lands in bytes that were already padding, so
88 stays 88. Encoding and Decode_Entry go 21 -> 23, which is +3,360 B per
table, +6.7 KB in all.
The per-form type is derived from llvm-mc rather than hand-written: assemble
each form's canonical word, disassemble it, take the suffix. 942 forms carry
one, 38 carry two. (`.w` is the Thumb wide qualifier, not a type, and is
excluded.)
Effect: of 202 shape groups holding more than one form, 168 are now separated
by the type -- 429 of the 489 unreachable forms become selectable. `dt` left
at .NONE means "unspecified" and still takes the first matching form, so
every existing caller behaves exactly as before.
It also fixes printing. The old inference could only ever produce one type,
so the whole convert family printed `vcvt.f32` -- 13 forms sharing one string
that no assembler accepts. They now print `vcvt.f32.s32`, `vcvt.f64.f32`,
`vcvta.u32.f64`, and so on.
Verified: vadd.i8/i16/i32/i64/f32 encode to f2010802 / f2110802 / f2210802 /
f2310802 / f2010d02, matching llvm-mc exactly; all 11 rexcode suites are
identical to baseline.
Still unreachable, 60 forms in 34 groups: register lists (VLD2-4/VST2-4),
LDM/STM addressing modes, and a few lane-indexed and fixed-point convert
forms whose element size is not captured by the type alone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Move all ten ISA packages (x86, arm32, arm64, mips, riscv, ppc, ppc_vle,
rsp, mos6502, mos65816) from core/rexcode/<arch> to core/rexcode/isa/<arch>,
so the import pattern is now `import "core:rexcode/isa/x86"`. The shared
core stays at core:rexcode/isa.
Mechanical: relative `import "../isa"` / "../../isa" -> absolute
"core:rexcode/isa" (the only path that survives the move; the "../" and
"../.." self/generated imports move with their packages). build.lua now
builds paths as <root>/isa/<name>; stale `cd <arch>` hints in the verify
tools and the doc.odin paths updated.
WASM stays at core/rexcode/wasm for now -- it is an IR, not an ISA, and
will move under the forthcoming core:rexcode/ir once that layer lands.
All 10 arches gen/builders/check/test green; import core:rexcode/isa/x86
verified working; wasm still compiles.
