Drew T
1.4 KiB
§332b ★★★ — THE §332 "WALLS" ARE A PER-OBJECT ASSEMBLER MODE, NOT A C LIMIT — 6 CLOSE AS REAL C (P31 S69, Fable-3)
§332 recorded the la-in-a-delay-slot class as unemittable from C at any closeness, and
oracle_reorder.py exists to prove a draft byte-correct-but-unemittable. The root cause is
narrower than that: the 800c3 / 800c2 band was assembled with reorder-mode slot filling —
a property of how those OBJECTS were built, not of the C.
Measured: a maspsx reorder-passthrough (3 lines) plus as -O2 is byte-INERT across the
whole 800c3 and 800c2 objects (P1 vs P2 .text identical) and yields 0 diffs for six walls
whose drafts already exist — func_80061FA8, func_8005FA94, func_8005D244, func_8005DBD8,
func_8005D734, func_80062144 — plus one at closeness 1. The other five never had correct drafts.
Implication: a per-object Makefile switch converts six "permanently unbankable" functions into
ordinary C banks, and retires oracle_reorder.py. Of the 15 previously-listed walls only 13 are
reachable at all (PopMatrix/PushMatrix are LINKED dead text).
The general lesson: when a class is declared unreachable by the toolchain, ask whether the property belongs to the TOOLCHAIN or to the OBJECT it produced. A per-object assembler mode looks exactly like a compiler limit from the diff.