re: read the three built-ins that appear inside clear conditions -- none named

isl-phase-guards produced the per-phase clear conditions, but three of the built-ins
in them were unread, leaving the conditions half-readable.  All three are read now
via the vtable at 0x820A84BC (control: 69 unit_state -> slot 184 -> 0x8226ADF0).
NONE is named: the corpus has withdrawn two names taken from usage shape, and what I
read does not support naming these.

builtin104 (slot 288, 0x8226BFE0) is a THREE-INSTRUCTION PURE GETTER:
    lwz r11, 10160(r3) ; stw r11, 164(r3) ; blr
So all six tutorial stages S18-S23 end on the value of a single engine-written word,
which is why their exits each have exactly one dominating condition and why
isl-builtins.md only ever saw 104 inside a poll loop.  That word has EXACTLY ONE
writer in the image -- sub_821AA1B0 at 0x821AAD9C, gated on a kind field being in
(16, 32] -- and r29 there is the return of a preceding call, so the meaning of the
value and of the gate are both unestablished.

builtin7 (slot 40) indexes [phase+324] by local[4], bails when rec+16 (the documented
unit state) is 1, 3 or 4, and resolves local[12] through [phase+244] -- symbol table 1.
isl.py's SYM1_SLOTS already listed slot 12 for built-in 7, derived from operand ranges
alone; reading the implementation shows the mechanism behind that.  Two independent
methods agreeing.  What it asks ABOUT the route is still unread.

builtin141 (slot 428) has the same unit-array entry and returns 0 when the unit is
gone; everything past 0x8226CA0C is unread.  Stage 16 calls it twice with arguments
differing in one position (0 vs -4000), which looks like a coordinate -- and looking
like one is exactly the evidence this corpus does not accept.

No artefact changes: the listings already printed builtin104/7/141 and still do.
All four Stage 02 artefacts regenerate byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 06:27:00 +00:00
parent b636ac9d4e
commit 7bd6342061
2 changed files with 121 additions and 0 deletions

View File

@@ -1464,6 +1464,20 @@ premise was wrong.**
in neither set also score 99.3 %. The control that works is the **tag word**:
`slot0 == 1` in 100.0 % / 100.0 % / **2.5 %**. Artefacts: calls + phase-ends
byte-identical, conditions changes on 28 sites (raw number → unit name).
**(2026-08-27) The three built-ins that appear INSIDE clear conditions are
READ — [structures/isl-condition-builtins](structures/isl-condition-builtins.md)
— but none is NAMED.** `builtin104` (slot 288, `0x8226BFE0`) is a **three-
instruction pure getter for `[phase+10160]`**, so all six tutorial stages end on
one engine-written word; that word has **exactly one writer** in the image
(`sub_821AA1B0` @`0x821AAD9C`, gated on a kind field in `(16, 32]`) and `r29`
there is a call result, so its meaning is unestablished. `builtin7` (slot 40)
indexes the unit array by `local[4]`, bails when `rec+16` (the unit state) is
1/3/4, and resolves **`local[12]` through `[phase+244]` = symbol table 1** —
independently confirming `isl.SYM1_SLOTS[12] ∋ 7`, which was derived from
operand ranges alone. `builtin141` (slot 428) has the same unit-array entry and
returns 0 when the unit is dead; the rest is unread. Its Stage-16 call pair
differs in one argument (`0` vs `-4000`) which LOOKS like a coordinate — exactly
the evidence this corpus does not accept.
Still unnamed: all 24. `builtin103` is a predicate over `[phase+10152]` and
`[phase+10156]` (no unit arg); `builtin105` tests a unit record's `+16` == 4
(`isl-builtins.md` documents `rec+16` as the unit STATE, 2 = active).

View File

@@ -0,0 +1,107 @@
# 🟡 The three built-ins that appear *inside* clear conditions — read, not named
[`isl-phase-guards`](isl-phase-guards.md) produced the per-phase clear
conditions, but three of the built-ins in them were unread, so the conditions
were only half-readable. All three are read now. **None of them is named** — the
corpus has withdrawn two names taken from usage shape, and what I read is not
enough to name these.
Implementations via the vtable at `0x820A84BC` (control: built-in 69
`unit_state` → slot 184 → `0x8226ADF0`, as recorded).
| built-in | slot | implementation |
|---|---|---|
| **104** | 288 | `0x8226BFE0` |
| **141** | 428 | `0x8226C9B8` |
| **7** | 40 | `0x82266C68` |
## ✅ `builtin104` is a pure getter — and it is the whole tutorial clear condition
```
8226BFE0 lwz r11, 10160(r3) ; r3 = the ScriptPhase
8226BFE4 stw r11, 164(r3) ; -> special[0]
8226BFE8 blr
```
Three instructions. It returns **`[phase+10160]`** and nothing else. So all six
tutorial stages (S18S23) end on the value of a **single engine-written word**
which is exactly why their exits have one dominating condition each and why
`isl-builtins.md` saw built-in 104 only ever inside a poll loop.
**That word has exactly one writer** in the whole image:
```
821AAD74 lwz r11, 104(r30)
821AAD84 lwz r11, 12(r11)
821AAD88 cmpi cr6, 0, r11, 16 ; skip if == 16
821AAD90 cmpi cr6, 0, r11, 32 ; skip if > 32
821AAD98 lwz r11, 4(r10)
821AAD9C stw r29, 10160(r11) ; <- the only write
```
inside `sub_821AA1B0`, gated on a type/kind field being in `(16, 32]`. `r29`
there comes from `or r29, r3, r3` — the return of a preceding call — so **what
the value means is not established**, and neither is what the gate selects.
🟡 Its neighbours belong to the same cluster: `builtin103` reads
`[phase+10156]` and `[phase+10152]` (9 and 7 writers), and a sibling vtable stub
clears `[phase+10152]`. The shape is an engine→script status trio, but that is a
description, not a name.
## ✅ `builtin7`'s mechanism — and an independent confirmation
```
82266C84 lwz r11, 324(r25) ; the unit array
82266C88 lwz r10, 4(r26) ; local[4]
82266C94 lwzx r11, r10, r11 ; -> the record
82266C98 lwz r10, 4(r11) ; the handle … (alive?)
82266CA4 lwz r11, 16(r11) ; rec+16 = the unit STATE
82266CA8..CBC ; bail if state == 1, 3 or 4
82266CC0 lwz r10, 12(r26) ; local[12]
82266CC8 lwz r11, 244(r25) ; [phase+244] = SYMBOL TABLE 1
82266CD8 lwzx r10, r10, r11 ; -> resolve local[12] as a symtab-1 index
82266CD0 lfd f31, 25600(r9) ; a double constant
82266CD4 lwz r9, 16(r26) ; local[16]
```
🔑 **`isl.py`'s `SYM1_SLOTS` already lists slot 12 for built-in 7**, derived
purely from operand ranges. Reading the implementation shows the *mechanism*
`local[12]` is indexed into `[phase+244]`, which
[`isl-bytecode.md`](isl-bytecode.md) documents as symbol table 1 (routes,
messages, objectives). **Two independent methods, same conclusion.**
That makes the Stage 02 phase-2 condition
```
builtin7(TCT206, 1, Route_TCT206_p2S, 4294967295, 500) == 1
```
structurally coherent — a unit, a **route symbol**, and two numbers — but *what*
it asks about the route is not read, so it stays `builtin7`.
## 🟡 `builtin141` — only the entry read
```
8226C9D4 lwz r11, 324(r29) ; unit array
8226C9D8 lwz r10, 4(r31) ; local[4]
8226C9E8 lwz r8, 4(r8) ; handle
8226C9F0 bc … 0x8226CA0C ; if alive, continue
8226C9F4 addi r11, r0, 0
8226C9F8 stw r11, 164(r29) ; dead -> special[0] = 0
```
The same unit-array opening as every unit predicate, returning 0 when the unit is
gone. Everything past `0x8226CA0C` is unread. Stage 16 calls it twice with
arguments differing in one position (`0` vs `-4000`), which *looks* like a
coordinate — and looking like one is precisely the evidence this corpus does not
accept.
## 🟡 Not settled
* **No name for any of the three.** For 104 that needs the meaning of `r29` at
`0x821AAD9C` and of the `(16, 32]` gate; for 7 and 141, their bodies past the
entry checks.
* `builtin103`'s fields `[phase+10152]` / `[phase+10156]` have 9 and 7 writers,
none read.
* This does not change any artefact — the conditions already printed
`builtin104`, `builtin7`, `builtin141`, and still do.