42544b4969
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.
87 lines
3.5 KiB
Markdown
87 lines
3.5 KiB
Markdown
# 🟡 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_coroutine` sites 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:
|
|
|
|
1. they are **unused in this build** — compiled from source that the shipped
|
|
mission never enters; or
|
|
2. 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_822737C8` and 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.
|