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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user