4f1f5ac0a2
Inverting the question -- read what an unreached routine DOES, rather than testing another candidate mechanism -- sharpened this a lot without solving it. The metric was partly inflated. Of 24901 unreached instructions in 564 runs, 458 runs are length 1, and 111 of those are a lone `ret` stranded after an end_coroutine, with the next routine being a properly seeded entry. Stage 02's first two "unreached routines" are exactly that. But those are only 458 instructions: the real gap is 24443 in 106 runs, the largest 1526 (Stage 26), 1496 and 1481 (Stage 29), 1069, 904. And it is live mission logic. Stage 26's 1526-instruction run stages arguments and calls builtin57(ADN110, 1) and set_group_speed(ADN110, 2, 0) -- named units, named built-ins. New this iteration: kill_coroutine (built-in 5) is confirmed as a code-offset carrier, which is what the corpus said -- its local[0] resolves 150/150 onto the instruction stream against a 34.0% control, values 13740..221048. And, like the others, it points at zero unreached run-starts. That is now five mechanisms. Across 2757 code references -- start_coroutine 1765, the phase timeline 675, built-in 19's trigger handlers 79, kill_coroutine 150, and the 0x1883 records 88 -- not ONE lands on an unreached run-start. A categorical absence, not a near miss. Not a tool artefact: 1765 of 1765 start_coroutine sites resolve with 0 missed, 0 entries land outside their phase region, and 0 are discarded by the on-stream filter. Combined with the earlier result that an unreached routine's offset appears nowhere in the file as a word in any encoding, these routines are referenced by nothing inside the .ssb. Either they are unused in this build, or they are entered from outside it. A 1526-instruction routine driving a named squadron sits badly with "unused", but that discomfort is not evidence and the two readings are recorded without choosing. No static test I have devised can decide it; a runtime probe logging sub_822737C8's third argument through a mission would. All artefacts regenerate byte-identical; documentation only.
3.5 KiB
🟡 The unreached code — five mechanisms eliminated, and nothing in the file names it
Inverting the question (read what an unreached routine does, instead of testing another candidate mechanism) sharpened this considerably without solving it.
✅ The metric was partly inflated — but only partly
Over all 28 stages: 24 901 unreached instructions (15.0 %) in 564 runs.
| runs of length 1 | 458 |
…of those, a lone ret (op 20) |
111 |
| instructions in runs longer than 1 | 24 443 — 14.7 % |
The length-1 runs are dead terminators: a ret stranded after an
end_coroutine, with the next routine being a properly seeded entry. Stage 02's
first two "unreached routines", 0x000D8C and 0x002C00, are exactly this — the
code immediately after each is the phase main entry and a timeline target.
But they are only 458 instructions. The gap is real: 106 runs, several of them huge — 1526 (Stage 26), 1496 and 1481 (Stage 29), 1069, 904, 860.
✅ And it is live mission logic
Stage 26's 1526-instruction run:
004BD8: local[0] = 1 ; local[4] = 1 ; local[8] = 1
004C08: call builtin57(ADN110, 0x1)
004C44: local[16] = 0.0
004C60: call set_group_speed(ADN110, 0x2, 0)
Named units, named built-ins, staged arguments. Not padding, not scratch.
🔴 FIVE mechanisms carry code offsets — and none points at it
Every construct in the file that names a routine has now been enumerated and tested against the unreached run-starts:
| mechanism | references | on the instruction stream | control | unreached run-starts |
|---|---|---|---|---|
start_coroutine (built-in 1) |
1765 | 1765 (100 %) | — | 0 |
| the phase TIMELINE | 675 | 675 (100 %) | 33.3 % | 0 |
| built-in 19's trigger handler | 79 | 79 (100 %) | 27.8 % | 0 |
kill_coroutine (built-in 5) |
150 | 150 (100 %) | 34.0 % | 0 |
the 0x1883 records |
88 | 82 (93 %) | — | (they were the 5 exits) |
kill_coroutine is new this iteration and confirms the corpus's reading — its
local[0] is a phase-relative code offset, 150/150, values 13 740…221 048.
Across 2 757 code references, not one lands on an unreached run-start. That is not a near miss; it is a categorical absence.
✅ Not a tool artefact
The obvious suspicion is that my entry extractor drops targets. It does not:
- 1765 of 1765
start_coroutinesites resolve — 0 missed. - 0 entries land outside their phase's region.
- 0 entries are discarded by the "must be on the instruction stream" filter.
🟡 Where that leaves it
Combined with the earlier result that an unreached routine's offset appears
nowhere in the file as a word, in any encoding (phase-relative, absolute, and
both /4 forms, all at or below their controls), the conclusion is that these
routines are referenced by nothing inside the .ssb.
Two readings remain, and this work does not choose between them:
- they are unused in this build — compiled from source that the shipped mission never enters; or
- they are entered from outside the file — a table in another pak, or engine code holding an offset.
⚠️ Reading (1) is not comfortable with a 1526-instruction routine that manipulates a named squadron, but "uncomfortable" is not evidence.
🟡 Not settled
- Which of the two readings is right. A runtime probe — breaking on
sub_822737C8and logging its third argument through a mission — would decide it, and no static test I have devised can. - Whether the 106 runs are one phenomenon or several.