Files
Odin/core
Brendan Punsky db2c234607 rexcode/arm32: LDMIB/LDMDA/LDMDB and STMIB/STMDA/STMDB are their own mnemonics
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>
2026-08-27 08:21:14 -04:00
..
2026-04-28 19:27:24 +02:00
2026-07-31 21:47:02 -04:00
2026-04-28 19:27:24 +02:00
2026-08-25 23:03:11 -07:00
2026-08-02 03:15:30 +02:00
2026-08-25 23:55:55 -07:00
2026-08-22 21:50:07 +02:00
2026-08-24 22:46:30 -07:00
2026-08-25 21:49:11 +02:00
2026-04-28 19:27:24 +02:00
2026-03-14 16:21:38 +00:00
2026-02-09 20:08:22 +01:00
2026-07-30 12:03:08 +02:00