The last surviving "compiler wall" of the session turned out to be an off-by-one-word
carve. Chain, all byte-grounded:
SYMPTOM jtbl_carve diverges on ov_SC06_018 after a BYTE-NEUTRAL jr_isolate_all.
SHAPE image -3 bytes; 853 differing bytes in 699 scattered runs; **812 at byte 0 of a
word** = the low byte of a 16-bit immediate, every sampled one changing by
exactly -4. Not a shift, not a pad: hundreds of `%lo` operands 4 bytes low.
CAUSE func_80191C50's own `sltiu $v0,$v1,0xC` names 12 entries; the emitted .rodata
holds 12 words; the carve reserved 13. The 13th word (0x3038200A) is ordinary
NON-ZERO data that spimdisasm ran into the dlabel span (the next dlabel sits
past it). Reserve 13 / supply 12 => the .rodata piece UNDER-FILLS by one word
=> every later symbol slides down 4 bytes.
WHY MISSED The trailing-trim's axiom is "0x00000000 cannot be a jump target", so it only
trims ZERO words. This surplus is non-zero, so nothing trimmed. The tool already
treats `sltiu` as ground truth - it EXTENDS a table spimdisasm cut in half, and
it WARNS when a span is too short - but had no clamp for a span too LONG.
FIX: an over-span clamp with the SAME authorization as the existing extension logic -
only when the `sltiu` bound is UNAMBIGUOUS (one bound; a multi-switch fn cannot say which
table owns which), and only when the surplus words are NOT plausible code addresses. If any
surplus word looks like a real entry it REFUSES LOUDLY rather than silently dropping one.
jtbl_carve: jtbl_801D3BA4: clamped 1 trailing NON-ZERO word(s) - func_80191C50's own
`sltiu 12` names 12 entries and the surplus is not code
Then: carve BYTE-IDENTICAL, draft spliced, **func_80191C50 (710 ins) BANKED**.
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
Retires the JTBL-CARVE-BREAKS-BYTES ledger class: the one instrument failure that survived
this morning's retraction round was REAL, and is now a named bug with a fix - not a wall.
Drew T
0958120006