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
CRC32 and its castagnoli variants are unconditional-only: the condition
field is fixed at AL. Their entries left bits 31:28 free, so every
condition decoded as a CRC32 that cannot exist.
VDUP from a lane packs the element size and the lane index into one
four-bit field -- `xxx1` is a byte lane, `xx10` a halfword, `x100` a
word -- and the two forms it had read that field as though it were an
ordinary by-scalar operand, which is a different layout entirely. The
word they named, with the field zero, is not an encoding at all. Six
forms now, two per element size, each with the size in its data type.
A coprocessor number is written `p15`. It had been printing as a plain
`#15`, which is not what an assembler takes, and it is a different kind
of thing from the CRn and CRm registers that were already spelled
`c0` -- so it gets a class of its own rather than sharing theirs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
The one-register-and-modified-immediate forms left the op bit and the Q
bit out of their masks. Those two bits are the whole difference between
VMOV and VMVN and between the D and Q widths, so a handful of D-form
entries answered for words that were neither -- a Q-width VMOV decoded
as a D-width VMVN. With them pinned the matrix has to be complete, and
it was not: only four of the ten cmodes had Q forms at all. Both
mnemonics now carry the full set, with cmode 1110 going to VMOV.I64
rather than VMVN when op is set, and cmode 1111 belonging to VMOV
alone.
VLDM and VSTM name their addressing mode, as LDM and STM do, so they
are VLDMIA and VLDMDB rather than one mnemonic apiece -- and the
decrement-before forms, which always write back, had no entries at all.
The broadcast structure loads are not mnemonics of their own. VLD2R and
friends are how the encoding is named, not how it is written: an
assembler writes `vld2.8 {d0[], d1[]}, [r0]`, a VLD2 with an all-lanes
list. They join VLD2, VLD3 and VLD4 as the forms they are, and the list
carries the spacing bit 5 gives it.
VFMA against bfloat16 names which half of each pair it takes on the
mnemonic, bottom or top. It had one form covering the top half under
the plain name and none for the bottom.
Every word the A32 sweep produces now round-trips through llvm-mc or is
one llvm's own disassembly cannot: 985 exact, 177 with no assemblable
text, 38 reserved, and PSB CSYNC and TSB CSYNC, which llvm does not
implement for AArch32.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
The last of the A32 sweep's disagreements, and they were mostly the
same shape: an operand the syntax names but no field encodes, left
printing as `#0`.
MRS names APSR or SPSR by the R bit; VMRS and VMSR name FPSCR and its
neighbours out of bits 19:16, which their masks had pinned shut so the
register could not vary at all; SETEND names LE or BE by the E bit.
Those are bare tokens in the syntax, which is what the special-register
classes already model, so the endian pair joins them as a register
class of its own. DBG read the whole eight-bit hint field where its
option is only the low four, so it printed the fixed bits above it.
RFE and SRS name their addressing mode the way LDM and STM do, so they
are four mnemonics each rather than one, and the P and U bits that pick
the mode are fixed bits of each form -- they had been left out of the
mask entirely, so every one of the eight words decoded as the DA form.
The writeback bit rides in the base register for RFE and in the
implicit SP for SRS.
VORR and VBIC against a modified immediate had no forms at all. Those
words fell through to the shift-by-immediate family that sits beside
them, and decoded as VSRA, VQSHRN and VQRSHRN with a shift of zero --
which is not a shift any of them can take.
The register field in an operand was fifteen bits, on the reasoning
that a register's raw value never passes 0x401F. Two classes do: the
coprocessor registers at 0x8000, and now the endian tokens at 0x9000.
Both were truncating silently. The field is sixteen bits, which fills
the word exactly. A memory base or index is always a GPR, so those stay
as they are.
The A32 sweep now round-trips 984 of its 1183 entries byte-exact
through llvm-mc, with nothing left that llvm and this disagree on: 159
are words llvm's own disassembly cannot assemble back, 38 are reserved
encodings, and the last two are PSB CSYNC and TSB CSYNC, which llvm
does not implement for AArch32 at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
The NEON one-register-and-modified-immediate forms -- VMOV, VMVN, VORR
and VBIC against a constant -- had no encoding on the value slot at
all. The routine that expands an 8-bit field by its cmode was already
written and already correct; nothing called it, so twenty-six forms
decoded their constant as zero.
Printing it back is a second problem. A modified immediate is a bit
pattern, and assemblers write it as one: in hex, or as a float when
cmode 1111 expanded it into one. Both are operand kinds of their own
now, so the VFP `vmov.f32 s0, #2.000000e+00` prints as the float it is
rather than as the decimal of its bit pattern.
Two more VMOV forms: the one that moves a pair of GPRs to a pair of S
registers encodes only the first of the pair, and the second went
unprinted rather than being named as the one after it; and the one that
moves a 32-bit lane to a GPR names the lane in bit 21, which it did not
read, so every lane printed as a bare register.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
The generator re-emits the encoding table from the typed one, and the
routine that writes an entry's flags names them one by one -- so
`cond_in_21`, added last commit, survived until the next regeneration
and then vanished, taking VSEL's condition with it. Every flag has to
be named there; the routine now says so.
VCMLA names its rotation twice over. The by-element forms put it in
bits 21:20, which is what the previous commit taught it, but the vector
forms put it in 24:23 -- so those read every rotation as two quadrants
further round than it was.
VLDR and VSTR count their offset in words, not bytes, and were sharing
the halfword-load encoding, which reads a split imm4H:imm4L field that
is not there. They named offsets no VFP load can take.
PSB CSYNC and TSB CSYNC are unconditional-only -- the condition field
is fixed at AL -- but their entries left bits 31:28 free, so any
condition decoded as a conditional PSB. A word with a real condition in
it is a plain hint, and that is what it now decodes as.
Also gone: the printer's last-resort data type, which guessed `.f32` or
`.f64` from the register bank whenever a form gave none. Instructions
that take no data type -- VLDR, VSTR, VORN -- got one anyway, and it is
not accepted syntax. The table is where a form says what suffix it
wants.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
VSHLL's widest form shifts by exactly the element size. No field holds
that amount -- the size is a fixed bit of the form, so the shift is too
-- and the form printed no shift at all, which reads as a different
instruction. VCADD and VCMLA name their rotation in degrees, 90 and 270
for one and all four quadrants for the other; both printed the raw
field, so every rotation read as `#0`. VSEL is an unconditional word
that still names a condition, in bits 21:20 and spelled on the
mnemonic; it printed a bare `#0` operand instead and no condition. Only
four conditions can be named and not in their usual order, so they get
a small table.
The shift amount had five bits, which cannot hold 32 -- the amount LSR
and ASR reach through a zero field. It silently wrapped back to zero,
which is why the previous commit's fix for those did not take. Memory
had a spare bit and the register operand had two.
Three forms were shaped wrong outright. VDUP from a GPR puts Vd in bits
19:16 with D at bit 7, not where NEON usually puts it, so it named a
register sixteen too high. VCVTA, VCVTN, VCVTP and VCVTM to a 32-bit
integer land in an S register whatever the source width, and the F64
forms had them landing in a D. VFMAL and VFMSL multiply pairs of
half-precision values, so their sources are half the width of the
destination -- S registers into a D, D registers into a Q -- and they
carried no data type at all. VJCVT likewise: it converts F64 to a
signed 32-bit integer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
The VFP fixed-point conversions were a handful of forms whose comments
named the 32-bit fixed-point variants but whose encodings all had `sx`
clear, so they were the 16-bit ones; two of them were duplicates
distinguished only by a looser mask. None of them decoded the fraction
width at all, because the operand slot had no encoding, so every one of
them printed `#0` -- and a `#0` fraction is not what any of these words
mean. The block is now the full matrix the architecture defines: three
floating-point widths by two fixed-point widths by four directions,
twenty-four forms. The fraction is the fixed-point width less the
imm4:i field, so the widest fraction is what a zero field encodes.
LSR and ASR reach a shift of 32 through a zero field -- a shift of zero
would be a MOV, so the encoding spends that value on the one amount
five bits cannot otherwise name. Both the standalone mnemonics and the
shifted operand of a data-processing instruction printed `#0`, which is
not the same instruction; PKHTB dropped its `asr #32` entirely, since a
zero amount prints as no shift at all.
USAT and USAT16 saturate to an unsigned width of zero to 31 and store
it as it stands, unlike SSAT and SSAT16, which store one less than a
signed width of one to 32. They had been sharing the signed encoding
and so read one too high.
The AES and SHA forms carry a bare element size -- `aese.8`,
`sha1c.32` -- and had no data type at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
VMLA, VMUL, VMLAL, VQDMULL, VSDOT, VCMLA and the rest of the by-scalar
family take one lane of a low D register as the multiplier -- `d0[2]`,
not `d0`. Every one of them printed the bare register, which is not only
missing information but assembles to a different instruction: the
by-vector form.
The forms already declared the operand type as DPR_ELEM; what they
lacked was an encoding that knows the register number and the lane
number share a single four-bit field. How they share it depends on the
element size, and the two splits are different enough to be separate
encodings: 16-bit takes Vm from bits 2:0, so D0..D7, and the lane from
M:bit3, giving four lanes; 32-bit takes Vm from bits 3:0, so D0..D15,
and the lane from M alone, giving two. The dot-product and complex
forms share the 32-bit split despite being 8- and 16-bit operations.
Those reaches are now checked when selecting a form, so `d8[0]` on a
16-bit form matches nothing rather than quietly encoding as `d0[0]`,
and a lane-less operand no longer matches a by-scalar form at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
Three unrelated things the A32 sweep turned up, all of them in what an
instruction prints rather than what it encodes.
VTBL and VTBX read their table from a run of one to four D registers,
and the run length is a fixed pattern bit of the form rather than
something the operand encodes. They printed a bare `d0`, which is not
the syntax -- the table is a list even when it holds one register. The
length now rides in the operand encoding, the way the NEON
structure-list lengths already do, and the encoder checks it, so
`{d0}` and `{d0, d1}` select different forms instead of both landing on
whichever sorted first.
The NEON compare-with-zero forms and VCMP/VCMPE against zero take a
literal `#0` that no field encodes. Modelling it as an implicit operand
is enough for it to print; nothing is emitted for it.
VCMP left bit 7 out of its mask. That bit is the E, which is the only
thing separating VCMP from VCMPE, so VCMP matched both and VCMPE could
never be decoded at all.
Also: VPUSH and VPOP take no data type, but the printer's fallback
guessed one from the register bank whenever the table gave none, and
produced `vpop.f64 {d0}`. A leading register list now suppresses it --
the load/store-multiple forms are exactly the ones that lead with a
list.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
SSAT, SSAT16, USAT and USAT16 encode their saturate position minus one,
and SBFX and UBFX their width minus one, so a field of zero means one.
All of them printed the raw field, which is not a value the instruction
can take -- `ssat r0, #0, r0` is not assemblable.
BFI and BFC are different again: their field is the top bit's position,
and the width the syntax wants is msb - lsb + 1. They shared an encoding
with SBFX and UBFX, which need the opposite arithmetic, so they now have
their own. Packing an msb needs the lsb from a sibling operand, so the
packer takes the instruction rather than one operand in isolation.
Also worth recording: the sweep had been running llvm-mc with
`-mattr=+all`, which that target does not recognise and silently
ignores, so every CRC32, FP16, v8.1a and dot-product entry looked like a
reserved encoding. With the features actually enabled, 815 of 1139 A32
entries round-trip, and 38 rather than 143 are genuinely reserved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
Forty-one groups of forms differed only in bits their own mask left
free, so they all matched each other's words and whichever sorted first
answered for the lot. That is where the NEON element sizes went:
`vabs.s8`, `.s16` and `.s32` are three patterns differing at bits 19:18,
and with those bits outside the mask the first one spoke for all three.
121 rows.
Two things that exposed:
- LDM and STM differ only in the writeback bit, and nothing in the
operand model recorded it, so the two forms printed identically.
Instruction carries it now and the base register wears its `!`.
- The T32 shifts left the S bit free, and their patterns sort ahead of
MOV's, so `movs.w r1, r2` came back as `lsl r1, r2, #0`. There is no
LSLS form in the table for it to have become instead; pinning the
bit at least stops it answering for a word that is not its own.
Also: r0 could not be used as an index register. The printer took a
register-offset operand to be immediate-only unless the index was
non-zero, when the class alone already says whether there is one --
`[r0, -r0]` printed as `[r0]`. And a displacement of zero lost its U
bit, which llvm-mc writes as `#-0` because it is a different word.
Against llvm-mc, A32 entries whose disassembly assembles back to the
same word: 760 of 1139, from 683. Wrong: 81, from 158.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
arm32 had only ever been checked against itself. Its sweep round-trips
our own encode and decode, which agree with each other whether or not
either is right -- exactly how the arm64 bugs stayed hidden for months.
Decoding each entry and handing the text to llvm-mc says something
different: 683 of 1139 A32 entries byte-exact, 166 wrong, 290 that no
assembler would take.
Three real faults out of that first pass:
- The halfword and dual load/stores split their 8-bit offset around
the opcode at bits 7:4, and their pre/post-indexed forms were using
the 12-bit decoder. It swallowed the opcode nibble, so `strht r0,
[r0]` came back as `[r0], #-176` -- 0xb0 being the halfword opcode
read as an offset. 16 forms.
- LDRD and STRD name a register pair and we printed one half of it.
The second is always the first plus one and occupies no bits, so it
needed an encoding that reads Rt and adds one.
- An indexed form printed no displacement when it was zero, which
turns `[r0], #0` into `[r0]` -- a different instruction, since the
writeback is the whole point of the form.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
No assembler spells these `vld1_lane` or `vmov_lane`; they are `vld1`
and `vmov` with a lane-indexed operand. All nine are now their base
mnemonic. Merging them meant fixing what the separate names had been
hiding.
VLD1_LANE and VST1_LANE were byte-for-byte duplicates of forms VLD1 and
VST1 already had, with a looser mask, and neither encoded the lane --
both used .VD_D, which has no lane field. `vld1.8 {d0[3]}, [r0]`
disassembled as `vld1.8 d0, [r0]`. VMOV had the same shape: its own
DPR_ELEM form dropped the index, while VMOV_LANE's three forms carried
the per-size encodings that actually work. The lane-dropping forms are
gone and the working ones now sit under the base mnemonic.
VLD2-4/VST2-4's single-lane forms left bits 9:8 free, and that field is
what separates VLD1/2/3/4 -- so VLD4's encoding matched VLD2's entry and
disassembled as the wrong instruction.
Two more things the lane could not survive. A lane index of 0 printed
nothing, because 0 doubled as "no lane" -- `vmov.32 d0[0], r0` came out
as `vmov.32 d0, r0`, a different instruction. And a lane inside a
register list was dropped entirely, so `{d0[1], d1[1]}` printed as
`{d0, d1}`.
The whole set is byte-exact against llvm-mc: 27 single-lane forms across
VLD1-4/VST1-4 and all three VMOV element sizes. arm32 is 1649/1649 on
the sweep and 436/436 on the table checks, with the stale expectations
for the forms this corrected updated to the verified values.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
`vpush {d8, d9}` came out as `vpush {r2}`. VFP list operands kept only
the 8-bit count from the encoding and stored it in a REG_LIST operand,
whose immediate the printer reads as a GPR bitmask -- so the register
bank was wrong, the start register was gone entirely, and the count was
read as a bitmask. `vldm r0, {d1, d2, d3}` printed `{r1-r2}`.
A list is now a register plus a shape: how many, and what the run steps
by. VLDM/VSTM/VPUSH/VPOP recover their start register from Vd and their
count from imm8. A GPR list stays a bitmask, since `{r4, lr}` is not a
run at all.
The NEON structure loads were wrong in a second way. VLD1-4/ST1-4 encode
their register count in the type field at bits 11:8, not in imm8, so
writing a count into the low byte overwrote size, alignment and Rm. Rm
was left at 0, which is a register post-increment, where the plain form
needs 0b1111; every one of those 23 forms encoded a writeback nobody
asked for. The count now comes from the form, the encoding writes only
Vd, and Rm is fixed in the pattern.
Deriving those counts from llvm-mc rather than by hand turned up a
dimension that was not modelled at all: the spaced forms step two
registers at a time (`vld2.8 {d2, d4}`), and VLD1 has a to-all-lanes
form written `{d2[]}`.
All 31 A32 list forms are now byte-exact against llvm-mc, from 8. The
arm32 sweep holds at 1656/1656.
Still open here: those forms only exist for .8 data, because the size
field at bits 7:6 is unencoded, and the writeback variants
(`[r0]!`, `[r0], r1`) are not modelled.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UmHLRF11EoWwNWCJ7JGaA
Asking for a VFMA with a lane operand emitted a VMLA. NEON's fused multiply-add
has no by-element form at all -- llvm-mc rejects `vfma.f32 d0, d1, d2[0]` -- and
the four rows sitting under VFMA/VFMS held VMLA/VMLS's lane encodings, which
VMLA and VMLS already own. Their data type gave it away too: `.I32` on a
fused multiply-add, which is float-only. Deleted.
They were also the reason `bits & ~mask` looked wrong on those rows: as
authored they were F2A000C0, and clearing the Vn high bit -- correct, since
bit 7 is the top of the register number -- landed them exactly on VMLA's
F2A00040.
Found by asking which (bits, mask, mode) triples more than one mnemonic
claims. That check found 18; this commit takes it to 9.
Three of the eighteen were whole mnemonics duplicating a base:
VRECPE_F, VRSQRTE_F every form already present under VRECPE / VRSQRTE,
which carry both the U32 and F32 variants.
VPADD_F its F32 form duplicated VPADD's; its F16 form was the
only thing it owned, so that moves to VPADD, where the
data type now selects it.
All three were on the list of names no assembler spells, so that count goes
from 14 to 11 -- and nine of the remaining eleven are the *_LANE group, still
waiting on register-list and lane-index modelling. The other two are
`psb csync` and `tsb csync`, which are correct as they are.
Two smoke checks asserted the VFMA/VFMS by-element forms and are gone with
them; a third moved index.
Verified against llvm-mc: vpadd.i8/.f32/.f16, vrecpe.u32/.f32 and vrsqrte.f32
all byte-exact, 1656/1656 decode sweep, every suite at baseline.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Collapsing the encoding-shaped mnemonics into their assembler names merged
several form lists that already overlapped, leaving byte-identical Encoding
rows inside one mnemonic. The matcher takes the first form that matches, so
every duplicate was dead weight -- unreachable, and inflating both tables.
VMUL, VMLA and VMLS each gained two from the *_LANE merge; VSHR, VSRA and
VRSHR two each, VQSHRN, VQRSHRN and VSHLL one each.
The branch base had none, so these are mine: the collision check I ran before
each merge compared operand signatures, which is the right test for "can the
matcher tell these apart", but says nothing about two forms being wholly
identical. Comparing the full Encoding would have caught them.
1680 -> 1665 forms. Removing an unreachable exact duplicate cannot change
behaviour, and does not: the load/store, LDM/STM and NEON data-type encode
checks are byte-for-byte what they were, and the decode sweep still round-trips
every form.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
LDM and STM each held five A32 forms with identical operand shapes -- the four
increment/decrement orders plus a writeback variant -- distinguished only by
their fixed bits. Nothing could tell them apart, so the encoder always took the
first and six of the eight A32 encodings were unreachable: `ldmib`, `ldmda`,
`ldmdb`, `stmib`, `stmda`, `stmdb` could not be produced at all.
They are not variants of one mnemonic in the first place. An assembler spells
them `ldmib` / `ldmda` / `ldmdb`, with plain `ldm` meaning IA, so this follows
the same rule as the rest of the enum: one member per name an assembler
accepts. LDM/STM keep the IA order and the Thumb encodings; the other three
orders become their own mnemonics, and the T32 DB encodings join them.
All eight now encode, byte-exact against llvm-mc:
ldm e8900006 stm e8800006
ldmib e9900006 stmib e9800006
ldmda e8100006 stmda e8000006
ldmdb e9100006 stmdb e9000006
Six test checks referenced these forms by index; they were re-derived by
matching (bits, mask) against the rebuilt table rather than by adjusting
offsets, and every one was found -- so no form was lost in the move.
Writeback (`ldm r0!, {...}`) is still unreachable: it is a property of the base
operand, not a separate mnemonic, and there is nowhere to put it yet. That is
one form per family rather than four.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The encoder builds a word by ORing packed operand fields onto the form's
`bits`. It can only ever set a bit that way, never clear one -- so any bit
`bits` presets that an operand is supposed to drive is stuck at 1 forever.
72 forms did that, and two families show what it cost:
* The U bit (23) on the whole A32 load/store family. U selects add vs
subtract for the displacement, and the encoder derives it from the sign of
mem.disp -- but every form had it preset, so `ldr r0, [r1, #-4]` silently
encoded as `[r1, #4]`. Every negative displacement in the family was wrong.
* The Vn high bit (7) on the NEON lane-indexed forms. That bit is the top of
the register number, so presetting it meant Vn could only ever name
d16..d31; d0..d15 were unreachable.
Which bits are operand-driven was decided by llvm-mc rather than by reading
the manual: for each of the 230 bits a form preset outside its mask, take the
form's canonical word with the bit set and cleared and disassemble both. Same
mnemonic, different operands means the bit belongs to an operand (clear it);
a different mnemonic, or an undecodable word, means the bit is genuinely fixed
for that form. The split was not per-bit -- bit 7 is a register bit for
VMUL/VMLA/VFMA but distinguishes VNEG from VABS and VCMPE from VCMP, and bit
23 is the U bit for LDR but the load/store select for VCX3 -- so every form
was classified individually.
Ten test expectations asserted the old values and were corrected; each had the
bug baked in. Verified byte-exact against llvm-mc across the load/store family
including every negative-displacement form, and the 1680/1680 decode sweep and
all other suites are unchanged.
The other half of `bits & ~mask != 0` -- 130 forms where the bit really is
fixed and the MASK is merely too loose -- is deliberately not in this commit.
Widening those masks alone breaks decode: a bit that distinguishes two
mnemonics has to be added to BOTH forms' masks in the same pass, and doing
only the ones that set it made LSL swallow MOVS, CX3 swallow VADDLVA and VABAV
swallow VRMLSLDAVH. That needs each form's true mask derived empirically
(vary the operands, see which bits move) the way specgen does it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Of the 38 mnemonics still carrying an encoding-shaped name, 24 were simply
names no assembler accepts, and arm32's printer emits the enum name verbatim
-- so `vldrb_gather`, `vceq_z`, `vmov_q_r` and friends were the printed
output. Judged against llvm-mc in every case:
renamed (base name was free)
BFI_BR -> BFX the V8.1M Branch Future indeXed, not a bitfield
insert; llvm assembles `bfx .L, r0` to F060E001,
which is exactly the bit pattern this entry held.
VDOT_BF16 -> VDOT `vdot.bf16 d0, d1, d2`
VMMLA_BF16 -> VMMLA `vmmla.bf16 q0, q1, q2`
merged into the base mnemonic (21)
VCEQ_Z/VCGE_Z/VCGT_Z/VCLE_Z/VCLT_Z -> the compare-against-zero forms
are the same mnemonic with a literal `#0`: `vceq.i8 d0, d1, #0`.
VCVT_FIXED, VCVT_BF16 -> VCVT `vcvt.s16.f32 s0, s0, #4`
VFMA_BF16 -> VFMA
VLDR{B,H,W,D}_GATHER, VSTR{B,H,W,D}_SCATTER -> VLDR*/VSTR*: an MVE
gather is spelled `vldrb.u8 q0, [r0, q1]`; the vector offset is an
operand, not part of the mnemonic.
VMOV_Q_R, VMOV_R_Q, VMOV_2GPR_Q -> VMOV
VHCADD_SAT -> VHCADD, VCMLA_MVE -> VCMLA
kept, but printed properly (2)
PSB_CSYNC / TSB_CSYNC are written as two tokens, `psb csync`, the same
shape as arm64's DC/AT/TLBI. The underscore now prints as a space; no
other arm32 mnemonic has one.
Every merged form had an operand signature the matcher could already tell
apart from the base's, so nothing became unreachable. 631 -> 590 mnemonics,
underscore-bearing names 58 -> 14.
Test indices were re-derived by matching (bits, mask) against the rebuilt
table rather than by computing offsets -- every index the tests reference was
found, which is a check that the merge dropped no form.
Still blocked, and for the two reasons already known:
VPADD_F, VRECPE_F, VRSQRTE_F -- collide with their base because the NEON
data type (.f32 vs .i8/.u32) is not an operand.
VMOV_LANE, VLD1-4_LANE, VST1-4_LANE -- register lists and lane indices are
not modelled.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The arm64 pass turned up the same class of bug elsewhere: mnemonics named
after an encoding rather than after what an assembler accepts, and forms
that no caller can reach because the thing that tells them apart is not
checked.
mips
* The printer mapped every `_` to `.`, but MSA spells the sign qualifier
with an underscore and only the element size with a dot: `adds_s.b`,
`max_s.h`, `copy_u.w`. `adds.s.b` is rejected by an assembler. 91
mnemonics were printing text that would not reassemble. The name alone
cannot decide it -- MSA's ADDS_S_D and the FP convert CVT_S_D have the
same shape and want opposite treatment -- so the family is read off the
form's feature.
* `encode` now takes `features: Feature_Set = FEATURES_ALL` and skips
forms outside it, mirroring `decode`, which has had that parameter all
along. That asymmetry was the reason 12 mnemonics carried an ISA-variant
suffix: with no way to say which MIPS you were targeting, the pre-R6 and
R6 encodings of `mul` had to be two enum members. They are now one
mnemonic with two forms. Eight of the twelve did not even need the
feature filter -- pre-R6 MADD takes rs,rt while the PS2 MMI MADD takes
rd,rs,rt, so operand matching alone separates them. Verified against
llvm-mc: pre-R6 `mul` 712a4002, R6 `mul` 012a4098, `madd $t1,$t2`
712a0000. The printer's hand-written override table is gone.
arm32
* 20 `*_LANE` mnemonics folded into their base. The lane form differs from
the base in an operand TYPE already (DPR_ELEM vs DPR), so the matcher
could always tell them apart; the split only cost us the printed name,
which was the enum name verbatim -- `vqdmulh_lane`, which no assembler
takes. VMOV/VLD1-4/VST1-4 are left alone: their lane forms collide with
the base because register lists and lane indices are not modelled.
riscv
* ZEXT_H and REV8 each carry an RV32 and an RV64 encoding with identical
operands, and the forms were already tagged rv32_only / rv64_only -- the
encoder just never looked. `encode` now takes `xlen: XLEN = .RV64` and
filters, so the RV64 encodings are reachable at all: zext.h 0805c53b and
rev8 6b85d513, both confirmed against llvm-mc.
mos6502
* SAX_NMOS folded into SAX. The undocumented NMOS store-A&X and the
HuC6280 register swap share the mnemonic `sax`; one takes a memory
operand and the other takes none, so they are just two form sets.
Verified: every rexcode suite matches HEAD exactly, all 13 packages build,
and MIPS mnemonics llvm-mc does not recognise drop from 448 to 354.
Still open: arm32 has 201 form signatures no caller can select, because the
NEON data type (.i8/.i16/.f32) is not an operand -- `inst_vadd(d0,d1,d2)`
always yields the first form, and only a decoder-supplied form_id hint can
pick another. 38 arm32 mnemonics still carry encoding-shaped names
(VPADD_F, VCEQ_Z, VLDRB_GATHER, VMOV_Q_R, ...).
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.
