re: derive UNIT_ARG from the implementations -- 31 built-ins take a unit, not 31 of 55

isl.py's UNIT_ARG decides whether a built-in's slot-4 operand prints as a unit name
or a raw number.  It was inferred statistically from operand ranges and, by its own
comment, listed a slot "only when the ratio stayed below 1.0" -- conservative.

The vtable base makes it a lookup instead: every unit-taking built-in's implementation
opens with lwz 324(phase) / lwz 4(argbase) / rlwinm 2,0,29 / lwzx / lwz 4(rec).  Read
directly for all 147:

  implementation indexes [phase+324] by an argument   55
  of the statistical set's 31, confirmed              31  (zero false positives)
  UNIT_ARG claims a unit, implementation does not      0
  implementation says unit, UNIT_ARG missed it        24

The 24 include builtin80, group_ratio_pct, is_engaged, set_unit_flags,
squadron_trace, wait_units_ready and deploy_and_wait.  Hand-verified by reading
builtin7, 16, 80, 105, 117 and 136.

Recorded because it nearly passed: my FIRST control -- whether the additions' operands
resolve to a symbol-table-2 index -- is worthless.  The additions score 100.0%, but so
do the 31 baseline (100.0%) AND the 92 built-ins in neither set (99.3%).  Symtab 2 is
dense enough that almost any small integer lands in it.  A control the negative class
also passes is not evidence.

The control that discriminates is the tag word: a symbol operand is a two-word pair
whose first word is the constant 1, so slot0 == 1 exactly when slot 4 is a unit --
100.0% (13677 calls) / 100.0% (140) / 2.5% (2903).  A 40x separation.

Artefacts: isl-stage02.txt and -phase-ends.txt regenerate byte-identical; -conditions
changes on 28 sites, every diff line pairing, each a raw number becoming a unit name.

Left unnamed on purpose: all 24.  builtin80 returns a small enum (tested 0..4 in a
switch) but its body past the liveness check is unread; builtin103 is a predicate over
[phase+10152]/[phase+10156]; builtin105 tests a unit record's +16 against 4.
This commit is contained in:
Sylpheed RE agent
2026-08-27 05:45:10 +00:00
parent 1ac9aa1d7d
commit 126539b875
4 changed files with 148 additions and 30 deletions

View File

@@ -1438,6 +1438,17 @@ premise was wrong.**
exact, and seeding the tracker at coroutine ENTRIES (`start_coroutine`'s target
is staged slot 0) would resolve the LHS. ▶️ **Still open:** the 35 unnamed built-ins (`builtin16` 132
sites, `builtin105` 117, `builtin103` 115 — each now a vtable-slot lookup);
✅ **(2026-08-27) partial — [structures/isl-unit-args](structures/isl-unit-args.md):**
reading the implementations shows **55** built-ins take a unit at `local[4]`,
not 31. All 31 of the statistical set are confirmed (**zero false positives**);
it missed **24**, incl. `builtin80`, `group_ratio_pct`, `is_engaged`,
`set_unit_flags`, `squadron_trace`, `wait_units_ready`. ⚠️ My first control
(operands resolving to a symtab-2 index) was **worthless** — the 92 built-ins
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).
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.
which condition guards each `END_PHASE` (needs the control flow between them);
the vtable's length. The condition lives in the `op10`/`op13` poll loop upstream of
the outro — e.g. phase 3 polls `unit_state(ADT308)` and branches back to