From 91b09955c89f500b5ba8596b7bf11121c11074cf Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 06:27:05 +0200 Subject: [PATCH] The shortlist points at VU microcode; the decomp extents are unverified 391 candidates on correct bytes, 73 under 16 immediates. The densest, 0x2dca20, 164 bytes with three distinct immediates, disassembles through tools/overlay-anchors as: xori.b $w0, $w0, 0xa2 ext $v0, $s0, 0, 1 addu $a2, $v0, $a2 xori.b and ext are VU1 mnemonics and three-operand addu is not MIPS32. Capstone is decoding COP2: 0x2dca20 is VU microcode. Same answer 0x2ee138 gave. That calls the frequency result into question more seriously than the displacement did. The measurement filtered on opcodes excluding COP2, so VU cannot explain the 391 counts directly -- but the function extents come from the decomp's CPU analysis, and if an extent spans a VU region the window scanned is mixed and the immediate set attributed to that function is not a function's. Status: the enrichment is real as a measurement of those windows; what the windows are is now doubtful. Next: verify decomp extents land on CPU code before trusting any of them -- decode a sample and require a plausible prologue. Same shape as the cd16485 check, and the fourth time a 'real shortlist' has needed one more verification first. 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 b2fa364..ce6aa1d 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -2541,3 +2541,50 @@ and reported every one with the same confidence as the kind that does. are a legitimate shortlist -- but the disassembly that would consume them must go through `tools/overlay-anchors`, whose output has now been checked against a word the build pins. + +### The shortlist points at VU microcode, not CPU code + +391 candidates on correct bytes, 73 with fewer than 16 immediates. The densest is +`0x2dca20` -- 164 bytes, **three** distinct immediates, one of which is `0xc0`. + +Disassembled through `tools/overlay-anchors`: + + 0x2dca20: bnel $a1, $fp, 0x2dca38 + 0x2dca24: lbu $a2, ($s7) + 0x2dca28: xori.b $w0, $w0, 0xa2 <-- VU + 0x2dca2c: ext $v0, $s0, 0, 1 <-- VU + 0x2dca30: b 0x2dcac8 + 0x2dca38: sll $a1, $a1, 4 + 0x2dca40: .word 0x0200202d + 0x2dca48: addu $a2, $v0, $a2 <-- 3-operand: MIPS-III, not MIPS32 + +`xori.b` and `ext` are VU1 mnemonics and the three-operand `addu` is not MIPS32 at +all. **Capstone is decoding COP2.** So `0x2dca20` is VU microcode, not a CPU +function. + +That is the same answer `0x2ee138` gave. Two of the densest candidates in the +"moby_classes offset" shortlist are vector-unit code. + +**This calls the frequency result into question again, and more seriously than +the displacement did.** The enrichment measured 391 CPU functions carrying +immediate `0x00c0` at 11x-45x over neighbours, and that measurement filtered on +opcodes 0x09/0x0d/0x0f/0x0c/0x05/0x06 -- which **excludes COP2**. So VU code +cannot explain those counts directly. But the *function extents* come from the +decomp's CPU analysis, and if any extent spans a VU region then the window being +scanned is mixed, and the immediate set attributed to that "function" is not a +function's. + +**Honest status:** the enrichment is real as a measurement of those windows. What +those windows are is now doubtful, because the decomp's extents have not been +verified to land on CPU code, and two independent spot-checks of the densest +candidates landed in VU microcode. + +**What this needs before it can be used:** verify that a known CPU function's decomp +extent actually contains CPU instructions -- same shape as the `cd16485` check. +Decode a handful of extents and require them to begin with a plausible prologue +(`addiu $sp, $sp, -N` or `lui $gp`). Any extent that does not is a mis-bound or +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.