☀️ 70% – adopt sixty-four exact owners on 175a3bdc6: eleven main-image functions and fifty-three scene sequences

[wowwheaties]

Summary

Seven commits on main (175a3bd), rebased today from b873d4e. Together they install 64 exact owners main does not have — 53 overlay scene sequences and 11 main-image functions, all at differing_halfwords=0. README 67.32% → 69.94%; check progress full-C bytes 562,036 → 598,688 (41.68% → 44.40% of executable), main-image 124,932 → 127,466, overlays 437,104 → 471,222. One register entry retires (resource_37b:0200101a named two bytes of alignment padding). No owner loses its source.

Overlay owners follow the call-binding contract: legacy Func_02xxxxxx names that bind to two runtime targets in the audited extent are separated into distinct declarations (_a suffix, per the field-scene-selector precedent) and declared as absolute_symbols on each owner's translation unit. Sources install at their registered paths, the overlay assembly regions become AlchemyC_ placeholders with referenced local labels kept, and retained-region, dossier, unmatchable and recon draft records retire with the assembly.

Main-image functions went through alchemy check integrate --apply (11 accepted, 0 rejected). The compiler_zero_rematerialization_mismatch group (080b6d30, 080b9dc4) is fully refuted by ordinary C89 spellings and is removed; 080b8db8 leaves compiler_entry_scheduling_module and 080b6e7c leaves compiler_commutative_address_mismatch for the same reason.

Second commit: make candidate-corpus-check aborts at the first candidate draft whose legacy call name binds to two runtime targets; twenty-two such drafts get _a/_b declarations with runtime symbols on retained candidate units (your retained-overlay-380/-383 shape, reviewed span = overlay evidence). No production C or bytes change. Owners whose reviewed span and overlay evidence disagree, or lack evidence, are left for you (findings comment).

Third commit closes overlay 37b. Its two unregistered executable owners are recovered as exact C through alchemy decompile / diff / adopt (resource_37b:02001b44, 164 bytes; resource_37b:02000c8c, 548 bytes), and alchemy unit flatten consolidates the forty-six exact owners. The approved GCC 2.96 route cannot compile that as one file (its scheduler loops or faults once about thirty of these wrapper-heavy scene functions share a module, while every function and each half compiles, and your 61-owner scene_382.c is fine), so the overlay stays three units by role — scene_37b.c, scene_37b_steps.c, scene_37b_actor_steps.c, plus your existing scene-event-runtime unit untouched — with conflicting declarations resolved at file scope and cross-owner call-word collisions bound bare/_a with runtime symbols, your 382 style. alchemy diff --unit reports 46/46 owners exact from the shared objects. Two owners of the earlier landing had reused your existing register names (SequenceA / SequenceC) and are renamed.

Commits four to six, same method: two address-named owners renamed by evidenced role; resource_39e:02000e94 (236 bytes) and resource_3b0:02000564 (588 bytes) recovered as exact C through decompile / diff / adopt (the 3b0 owner carries _a/_b/_c call aliases with runtime symbols; adopt writes the register and retires evidence but stops at its own source check when a retained call-identity unit exists, so the unit and placeholder were finished in the tool's own output shape). Neither overlay can be flattened yet: 39e has six and 3b0 four reviewed owners still retained (listed in the commit bodies).

Commit seven: three more resource_39e owners recovered as exact C (02000104 IntegrateEffectMotion, 02000388 SceneData_SelectRecordByScene3cAndFlag895, 02001160 FieldScene_RunFiveActorBeatAndSetFlag301).

Rebase onto 175a3bd

Nothing in the branch touches tools/, so the workspace consolidation, the data-described asset build and the retired wave/family/dashboard surface apply unchanged. Conflicts were confined to the keyed registries and the generated figures: source-paths.json, translation-units.json and dossiers.json merged entry-by-entry, each surviving entry kept verbatim, and make coverage regenerated the SVGs and the README status line at each commit. The only entries that leave are the ones your own tools retire: 29 dossiers that adopt drops as their owners become exact, five 37b translation units that unit flatten absorbs (their three owners land in overlay-37b-steps), and the one padding register entry. Your overlay 376 and 385 recoveries and the seven dossiers you added are untouched; this branch works on 372, 373, 375, 377, 37b, 37f, 381, 383, 38e, 395, 396, 39a, 39e, 3a8, 3ab, 3af, 3b0, 3b1, 3b9, 3ba, 3bb, 3bc and 3bf. git diff --check is clean on every commit.

Gates (on 175a3bd)

• make verify, test, targets, classification-check, progress-report, coverage-check: green on every commit. full ROM contract ok: gs1-en, identical=True, unowned_bytes=0.
• alchemy check owners: owner registers ok after every adoption — 0 unmatchable, 0 sealed, 0 drafts.
• candidate-corpus-check: fails on untouched 175a3bd at Func_02008bd8: ambiguous overlay call identity ({200c954, 200c95c}). With the second commit it runs past that group and stops at Func_0200778c ({200daac, 200dad4}) in resource_39c — same class, your code, not separated here because its reviewed span has no overlay-assembly.json evidence.
• correspondence-check: fails identically on untouched 175a3bd at resource_385:02000cc8: ja overlay owner differs at +0x58 (c4 != b8), in the actor-presentation overlay landed today. Overlay locality otherwise reaches 3095/3139 matched here against 3042/3086 on main.

Review notes

• Compiler here is a linux-x64 source build of the pinned agscc 5ec3e2e + agbcc da598c1 with GNU binutils 2.10 GAS as as; make verify reproduces the ROM byte-exact with it, so the digests admitted locally for linux-x64 are xgcc 8d820fc3…, cpp0 067cb31d…, tradcpp0 faeae3eb…, cc1 fc3c3172…, as 8eb4386c…, agbcc/old_agbcc 6f02c717… (Ubuntu binutils 2.42 quirk: -mfpu=softfpa objects are flagged VFP, so as is wrapped to -mfpu=fpa). Nothing in the branch changes the pinned digests.
• Eleven more overlay owners from the earlier line remain non-exact under this pin (1–25 halfwords each; the list is in the previous findings comment) and are withheld.
• Four exact owners are withheld because they sit inside generated_call_script_module retained regions marked proven (resource_374:02000bbc, resource_399:02000f90, resource_39e:02000658, resource_39e:0200071c); their byte-exact C is available as a refutation of those records if you want it.
• The new CONTRIBUTING asks for related owners grouped in maintained modules rather than one-function files. 37b is already in that shape here. Say the word and I will reshape the rest of the overlays the same way instead of re-landing the per-owner form.

[wowwheaties]

Independent re-check of every overlay owner this branch adopts (152, listed from source-paths.json vs 9dbf29f), each scored one at a time with overlay score <adopted source> --owner <owner> --span <regions.json span_bytes> on 8cb65f1: 150/152 differing_halfwords=0. The other two are resource_371:02002cb4 (1146 vs registered 1148) and resource_3a6:020011a0 (182 vs 184): both are exact through their final return, and the registered span includes the alignment halfword after it (the same shape as resource_378:0200290c, adopted 1930 inside its 1932 region), so they read dh=1 at the registered span and dh=0 at the adopted one. The registry spans are left as they were.

[wowwheaties]

Re-landed on 90687df (one commit, d2c17eb): 54 owners at differing_halfwords=0 — 44 overlay scene sequences and 10 main-image functions, README 67.95% → 68.71%, make verify green. Beyond the owners, four things from this pass may be useful to you:

1. linux-x64 admission of the restored bundle. Built from the pinned agscc 919451b + agbcc da598c1 sources with GNU binutils 2.10 GAS as as; the full gs1-en ROM is byte-identical, make test/compiler-regression-check pass. Digests from that green verify, if you want to pin them:

xgcc      8d820fc39d325880901e3a97cbdcd22f23ab0a07466badb69c4f84a0ff47aef8
cpp0      067cb31d4530fadd8e1db62f0ab9c0c56b8b1b160fa586fc2d6471ccc1dfcbe5
tradcpp0  faeae3ebdfa029ad972e30ccd7fd19797686437790d99e58aff9955b1908baa2
cc1       1a4d19ceaa06e91214134baf8e87f19a26ad5e36ad3850c266052c6860d0a526
as        8eb4386cb65b04ccfee4c9708501c981d2f0399712545844e0f376c5a3ab33df
old_agbcc 6f02c7175ab43dea778afe0aebab0c45f872cbba231c8fcde7549e8d72aef1fe

One host quirk: Ubuntu 24.04 binutils 2.42 flags -mfpu=softfpa objects as VFP (e_flags 0x604) and ld refuses to merge them with the GAS-2.10 compiler objects (0x204); -mfpu=fpa in assembly_command yields 0x204 and links. Everything else in the route was untouched.

2. Evidence on the post-reload constant-mode correction. 19 overlay owners that were exact under the previous pin changed bytes under this one, all the same way: identical constant arguments now share one register where the ROM materialises each separately. Smallest cases (both were exact before):

• resource_371:02000c28 — Call4(Func_02005056, -1, -1, -1, 0): ROM movs r0,#1 … movs r1,#1; movs r2,#1; movs r3,#0; negs r1; negs r2; negs r0; now movs r0,#1; negs r0; adds r1,r0; movs r3,#0; adds r2,r1 (8 bytes shorter).
• resource_375:0200150c — Call3_120(Func_020031ca, 188 << 17, 188 << 17, 15): ROM movs r2,#188; movs r0,#15; lsls r1,r1,#17; lsls r2,r2,#17; now lsls r1,r1,#17; adds r2,r1,#0.
  HImode/(s16) respellings do not change it. If the corrected cselib is right, these 19 (and, I suspect, most of the 91 you dropped with the re-pin) are compiler-unemittable rather than mis-spelled; if the ROM is right, the correction is too eager on post-reload CONST_INT reuse. Sources for all 19 are available on request.

3. alchemy adopt cannot land colliding-name overlay C. Every scene sequence here has legacy names bound to two runtime targets (up to 17 per owner), which the contract resolves through absolute_symbols on a translation unit. But the unit cannot exist when adopt scores: an exact-c unit is rejected while the .s still owns the bytes (state disagrees with production C/assembly ownership), and a retained unit is rejected once the register has the path (is not a complete unmapped reviewed retained overlay owner), which overlay adopt --apply demands first. So no ordering works from the CLI; this PR reproduces adopt.rs by hand (register → listing-derived region lines → AlchemyC_ placeholder with referenced .L_ labels → unit → region/dossier/draft retirement → check owners). If you'd rather have that as a PR against the tool, say so.

4. Refuted records. compiler_zero_rematerialization_mismatch (080b6d30, 080b9dc4) links byte-exact from ordinary C89 and is removed here. Four further exact owners sit inside proven generated_call_script_module regions (resource_374:02000bbc, resource_399:02000f90, resource_39e:02000658, resource_39e:0200071c) and are withheld rather than editing that evidence; three call-target-mismatch residues closed by separating the colliding declarations one call site at a time, which may be worth a catalogued repair in alchemy match.

[wowwheaties]

Findings from today's lanes on 90687df, for your judgement (nothing here is in the PR beyond the exact owners):

1. Register alias families. Where translation-units.json declares a colliding callee as NAME_a/NAME_b with no bare NAME, a candidate that spells the second site with the bare name or an ad-hoc _a binds both sites to the first target and shows as call-target-mismatch forever. Spelling the sites with the declared family names in site order closes it (resource_3a2:02000924 is in this PR that way). If overlay adopt is meant to rewrite bare names to the declared family, it did not for this owner; if the bare name is meant to be an error, a lint would save future drafts from the same wall.

2. A floor class blocks most of the near-exact tail. 26 owners (11.9 KB) sit at differing_halfwords ≤ 5 with wrong_instructions=0, topology equal, and a residue that is one of:

• two independent ready instructions in the other order (a strb vs the mov r2,r8 address materialisation for the next statement — identical residue in resource_382:02001090 and resource_385:02000c1c; a movs r2,#0 vs lsls r1,r1,#7 argument setup in main:08095dd0; a hoisted ldr rN,[pc] one slot early in main:080a8578 / main:080cd260 / main:08020198);
• a register choice for a value with one use (ldr r1 vs ldr r3 for the ident compare in main:080fa264, MPlayContinue; r2 vs r3 for the pool constant in resource_383:02001348; r0 vs r2 for a loaded compare operand in resource_3a5:020004e4);
• the epilogue trampoline pop {r1}; bx r1 (the function returns a value the draft discarded — fixable, and worth a lint: two owners closed once the return type was corrected).
  Every source respelling we tried on the first two kinds (wrapper calls, temps, statement order, loop shape, join points, declaration order; 5–10 forms per owner, notes in the lane results) either held or regressed by re-allocating the whole block. Your scoreboard already names these classes (scheduling_floor, allocation_uncovered); the question is whether owners in this state qualify for a classification record the way compiler_zero_rematerialization_mismatch did, because that is where the remaining bytes are: of 396 fresh and re-scored drafts today, 85 are at ≤ 20 halfwords and only 7 reached 0.

3. Fresh drafts. alchemy decompile seeds for the 110 no_candidate main owners and 400 unregistered overlay owners scored between 30 and 1,100 halfwords; cheap-model passes converge within 3 passes and then stall (main: 105 rows, 0 exact). The candidate sources for every row are available if you want them as recon drafts.

Owners at ≤ 5 (dh, bytes): main:080b6d30 1/—, main:0801faa8 1/160, resource_39b:02001730 1/572, main:080fa264 2/28, resource_387:02000d68 2/64, main:080b6a60 2/128, resource_373:020032b0 2/208, main:08098848 2/268, main:08095dd0 2/460, resource_3a5:020004e4 2/936, resource_383:02001348 2/1608, resource_3a0:02000324 3/52, main:080a8578 3/140, resource_382:02001090 3/172, resource_385:02000c1c 3/172, main:080cd260 3/248, main:08021d88 4/114, main:080b0958 4/164, main:08020198 4/172, resource_3af:02001db0 4/480, main:080e0c84 4/956, resource_378:0200088c 4/4080, resource_3b1:02001978 5/144, resource_39c:020016c4 5/204.

[wowwheaties]

Findings from running the full make audit set on 699b9d6 with a linux-x64 source build of the restored pin (all six ROMs present), for your judgement:

1. candidate-corpus-check aborts on the first draft with a colliding legacy call name (Func_02008bd8 in resource_380:02004260), and behind it on every later such draft, so the audit never reached the 3ax–3cx corpus. The second commit on this branch separates those names into _a/_b declarations with runtime symbols on retained candidate units (your retained-overlay-380/-383 shape), and names two intra-extent callees the reference never reaches by bl. With that the audit runs to completion: sources=280 nonexact=49 exact_retained=0 exact_unmapped=1 unverified_retained_fragments=10.

2. Twelve corpus owners cannot carry a unit under both checks. check integrate requires a unit owner's extent to equal the reviewed span in games/gs1/semantic/regions.json; build-full requires it to equal the sum of that owner's overlay-assembly.json regions. They disagree for: 371:02000c28 (2354 vs 2352), 38d:020019b0 (2060/2002), 39f:02002500 (1640/942), 3a4:02001838 (1236/1208), 3a5:0200088c (940/910), 3a8:020026c0 (2756/2710), 3b9:02001cd4 (1804/1778), 3bb:020010dc (532/508), 3bd:020013f8 (6220/6210), 3c9:020008b4 (2508/2454), 3c9:0200423c (1692/1274), 3af:02002c84 (1228/966). Ten of them the audit already skips as unverified-retained-fragment; resource_3bd:020013f8 and resource_3c9:0200423c it compiles, and their colliding names still abort it there — that boundary reconciliation is yours. resource_39c:02001c9c, resource_3b3:02002384 and resource_3ba:02000540 are the mirror case (39c shown): regions.json gives it a 160-byte retained candidate extent but overlay-assembly.json has no evidence for it, so build-full rejects any unit (has no overlay assembly evidence) while the audit compiles its draft and aborts on Func_0200778c ({200daac, 200dad4}). Until those records exist the corpus audit stops at 39c; with temporary units for all three it ran to completion (that is where the numbers above come from). resource_3af:02002c84 also names four callees by their own resource address (Func_02000bb8 …) instead of the reference call word, and 0x020039ec is reached from six differently named sites, so it needs the same per-site treatment.

3. exact_unmapped=1: resource_37a:02001be8. Its byte-exact C moved back to the corpus in 699b9d6; the audit flags it as an exact candidate without a placeholder.

4. correspondence-check fails on your new owner resource_3c5:02001b10 (FieldScene_RunActorEventSequence): ja overlay owner differs at +0x400 (2f != b8) while cross-edition --span 2396 reports core_identical=yes for all six editions. Same result on your untouched tip here, so either a JA dump difference (all six ROMs here are header version 0) or a symbol whose EN address is not among the paired call targets.

5. Environment notes for make test / make audit on a fresh host: dashboard-server tests::music_client_regressions needs bun on PATH; family_m2c tests need upstream m2c cloned into m2c/; three families/waves tests read out/gs1-en/reports/compiler-families.json, which make families produces but audit orders after test.

[wowwheaties]

Rebased onto 175a3bd and re-verified there; the PR is mergeable again and the body is updated with the new numbers.

Nothing in the branch touches tools/, so the workspace consolidation, the data-described asset build and the retired wave/family/dashboard surface applied unchanged. Conflicts were only in the keyed registries and the generated figures. source-paths.json, translation-units.json and dossiers.json were merged entry-by-entry rather than by text, so every surviving upstream entry is byte-identical to yours, and make coverage regenerated the SVGs and the README status line at each of the seven commits. The only entries that leave are the ones your own tools retire: 29 dossiers adopt drops as owners become exact, five 37b translation units unit flatten absorbs (their three owners land in overlay-37b-steps), and the one register entry that named two bytes of alignment padding. Your 376 and 385 recoveries and the seven dossiers you added today are untouched. git diff --check is now clean on every commit.

On 175a3bd: 64 exact owners, README 67.32% → 69.94%, full-C bytes 562,036 → 598,688. make verify, test, targets, classification-check, progress-report and coverage-check are green on every commit.

Two audit gates still fail, both identically on untouched 175a3bd:

• correspondence-check stops at resource_385:02000cc8: ja overlay owner differs at +0x58 (c4 != b8), in the actor-presentation overlay you landed today. Overlay locality otherwise reaches 3095/3139 matched here against 3042/3086 on main.
• candidate-corpus-check stops on main at Func_02008bd8: ambiguous overlay call identity ({200c954, 200c95c}). With the second commit here it runs past that group and stops at Func_0200778c ({200daac, 200dad4}) in resource_39c — same class, but its reviewed span has no overlay-assembly.json evidence, so I left it for you rather than guess the split.

The new CONTRIBUTING asks for related owners grouped in maintained modules instead of one-function files. Overlay 37b is already in that shape here. Say the word and I will reshape the remaining overlays the same way rather than re-landing the per-owner form.