From d4aeb94616b1f09435b96a19fd29daa0a9ec8d10 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 06:28:26 +0200 Subject: [PATCH] Extent check inconclusive; the opcode field itself is not understood Tried to answer whether the decomp extents land on CPU code by checking for a prologue. Only 29 of 3,835 matched 'addiu $sp,$-N' or 'lui $gp' -- but the other bucket is full of textbook prologues my two patterns miss, because PS2 leaf functions save registers with no frame adjustment: 0x2a4ef0 ffb00000 ffb10008 sw $s0,0($sp); sw $s1,8($sp) 0x2a48f0 3c013f80 44816000 lui $1,0x3f80; bc1t Not reading a result into that. Separately, ffb00000 has major opcode 0x3f, unused in MIPS32, yet is unmistakably a register-save prologue and ffbf0020 for 'sw $ra,0x20($sp)' appears throughout this code. Either the EE encodes sw outside MIPS32 or I am reading the opcode field wrong somewhere. Not resolved -- and it undercuts every opcode-based check in this investigation, the 391 and the neighbour ratios included. Position after twenty-one commits: the mapping is verified, two targets are VU microcode, and the candidate windows are not established to be CPU code. What this needs is one authoritative disassembly of one extent compared against tools/overlay-anchors, to establish what the opcode field means. That is the same mistake one level down from the section-indexing bug: using a decoding never checked to produce results, then measuring those results with the same unverified decoding. 286 passing with the disc present, clippy clean. --- docs/plan/level-assets.md | 47 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index ce6aa1d..6327683 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -2588,3 +2588,50 @@ VU-overlapping window, and the 391 has to be recomputed over the survivors. That check is cheap, it is the same check that would have caught this six commits ago, and it is the honest next step. It is also, at this point, the fourth time a "real shortlist" has turned out to need one more verification first. + +### Extent check: inconclusive, and I am not going to read a result into it + +Tried to answer `91b0995`'s question -- do the decomp's function extents land on +CPU code? -- by checking whether each begins with a prologue. Counting only +`addiu $sp, $sp, -N` and `lui $gp`: + + total 3,835 | cpu prologue 29 | VU-first 66 | nop-first 243 | other 3,492 + +**29 of 3,835 looks damning and is not.** The "other" bucket contains textbook +prologues that my two patterns miss: + + 0x2a4ef0 ffb00000 ffb10008 sw $s0,0($sp); sw $s1,8($sp) + 0x2a48f0 3c013f80 44816000 lui $1,0x3f80; bc1t <-- valid CPU, FP branch + 0x2a4928 0240282d 24060002 slt $v1,$s0,$s1; sltu $a2,$zero + +PS2 leaf functions routinely start by saving registers with no frame adjustment, +and functions whose extent starts after the `addiu $sp` look the same. Two patterns +cannot classify 3,835 extents. + +**A second thing I cannot explain, recorded rather than guessed:** `ffb00000` has +major opcode `0x3f`, which is unused in MIPS32 -- yet `ffb00000 ffb10008` is +unmistakably a register-save prologue, and `ffbf0020` for `sw $ra, 0x20($sp)` +appears throughout this code. Either the EE encodes `sw` outside MIPS32, or my +opcode field is being read wrong somewhere. **I have not resolved this**, and it +undercuts every opcode-based check in this investigation, including the ones that +produced the 391 and the neighbour ratios. + +**So the position after twenty-one commits on `moby_anim`:** + +- `overlay_bytes_at` mapping: verified +- `0x2ee138`, `0x2dca20`: VU microcode, verified +- the 391 candidates: real as a measurement of the windows scanned; what those + windows are remains unestablished, because the window boundaries come from the + decomp and those have not been shown to delimit CPU code +- **the opcode field itself is not understood well enough for these checks to be + trusted**, which invalidates the last few in particular + +**What this needs:** a single authoritative disassembly of one extent, compared +line by line against `tools/overlay-anchors`, to establish what the opcode field +means for this code. Everything else is downstream of that and I have been +reasoning upstream of it. + +That is the same mistake one level down from the section-indexing bug: I used a +decoding I had never checked to produce results, and then measured the results +with the same unverified decoding. The check existed as a tool from the first +commit.