From 56b00fb305177f8f266aff73a4d20026f276e17e Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 05:17:47 +0200 Subject: [PATCH] Fix the immediate scan by filtering on opcode; still no signal Saying the previous method 'cannot tell' was right but the reason deserved a step rather than a hand-wave: it is fixable by counting immediates only where they are immediates, which needs an opcode filter and no disassembler. All 27 levels: 11,911,320 instructions, 2,985,897 carrying an immediate (addiu/lui/ori/xori/andi/sltiu), 13,813 distinct immediate values. moby_classes 0x00c0 17,699 tie_classes 0x1e80 17 And now there is a control the raw version never had -- the program's most frequent immediates are 0x0001 (200,784), 0x001b (149,259), 0x0010 (137,523), 0xffff (98,312). 0xc0 at 17,699 sits below the top of that small-value cluster rather than standing out, so it is not a distinctive reference. Result unchanged from the raw scan and now defensible: no signal. The loader is not findable by frequency, and the remaining route is structural dataflow -- functions touching both the chunk offset and a class span. No test: asserting that an offset is unremarkable is not an invariant worth locking, and the two numbers are already recorded with their denominator. --- docs/plan/level-assets.md | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 06314f3..28d7792 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -1956,7 +1956,29 @@ whole scan is confounded by value frequency, which is rule 3a again, one level below where it has bitten before -- not the measurement being wrong but the *comparison* having no shared denominator. -Doing it properly means decoding instructions and counting immediates only where -they are immediates, which is what `tools/overlay-anchors` is for. Until that -exists the answer is not "moby_classes is referenced more" or "less", it is -"this method cannot tell". +Doing it properly means counting immediates only where they are immediates. + +**Done, and it needs no disassembler** -- filter on opcode and take bits 15..0. +Counting only instructions that carry an immediate (`addiu`, `lui`, `ori`, +`xori`, `andi`, `sltiu`) across all 27 levels: 11,911,320 instructions, +2,985,897 with an immediate, 13,813 distinct immediate values. + + moby_classes 0x00c0 17,699 + tie_classes 0x1e80 17 + +Now the comparison has a denominator, and it has a control that the previous +version lacked: the most frequent immediates in the whole program are + + 0x0001 200,784 0x0010 137,523 0x0004 57,248 + 0x001b 149,259 0xffff 98,312 0x0002 64,450 + +So 0xc0 at 17,699 is *below* the top of the small-value cluster rather than +distinctive. The previous commit's "this method cannot tell" was right, and the +reason was worth one more step rather than a hand-wave: the method was fixable by +filtering on opcode, which costs nothing and needs no capstone. + +**Result: still no signal.** Nothing in the immediate stream points at +`moby_classes` more than at the other small offsets the program uses. The loader +is not findable this way, and the remaining route is structural -- finding +functions that touch both the chunk offset and a class span, which means real +dataflow rather than a frequency count.