[ISA v0.56] Resolve BSTART Mode=1 vs TEPL encoding collision

[zhoubot]

Problem

The v0.56 golden encodings permit a two-bit Mode on these headers:

• BSTART.MPAR
• BSTART.MSEQ
• BSTART.VPAR
• BSTART.VSEQ

For Mode=1, their raw words are respectively:

• 0x02001181
• 0x02009181
• 0x02021181
• 0x02029181

Those words are identical to BSTART.TEPL with TileOpcode 0, 1, 4, and 5.

Cross-component impact

• LLVM uses VS8=0 and VS16=1, so Mode=1 is reachable.
• QEMU currently fixes bit 25 to zero for the four non-TEPL headers and decodes the colliding words as bstart_tepl.
• Sail extracts the two-bit mode, but the current exec_bstart_* paths do not consume it.
• Simply widening the QEMU patterns from %ModeHi to %Mode would create ambiguous decodes and is not a valid local fix.

Required architecture decision

Freeze one coherent contract before changing any decoder:

1. reserve/remap the colliding Mode value; or
2. constrain/remap the TEPL selector space; or
3. define an unambiguous encoding/priority rule with equivalent semantics across all implementations.

Acceptance criteria

• ISA golden and manual define the legal Mode values and TEPL selector constraints without one-word/two-meaning encodings.
• LLVM assembler/disassembler follows that contract.
• Sail, QEMU, and LinxCore decode the same raw words identically.
• Exact raw tests cover all legal Mode values and TEPL selectors.
• Illegal/reserved colliding words have an explicit trap/reservation test.
• QEMU exact-signature coverage is updated only after the cross-component contract lands.

Guardrail

Until this issue is resolved, do not widen the four QEMU decoders or claim the missing Mode forms as covered through aliases/decoder priority.