116: worker A's hypothesis that the ranker cannot see LIVE RANGES (its conversion rate went to
zero over three consecutive rows, all failing on register allocation with the structure fully
confirmed). I tried to make it computable -- callee-saved registers saved and s-registers per
call -- and the proxy FAILED: matches span 0.00-2.00 s/call and failures span 0.17-1.33, with
a matched row having the HIGHEST s-register count and another matched row having 16 calls and
0 saved registers. The hypothesis is not refuted; the proxy is just not a good
operationalisation of 'live range'. Recorded as an open axis.
117: worker C's new signature -- correct control flow, +3 instructions, all three being j/jr
delay slots. DISTINCT from a nesting error (both give a small residual, but nesting moves
branch displacements while this moves instructions ACROSS a jump). Belongs with the post-pass
family.
118: call COUNT does not separate a real block from a call chain -- worker C's matched
0x80058CE8 is four loops that each call, and its false positive has zero calls. Fails in both
directions; recorded so nobody re-derives it.
Worker B's 0x80050CA8 (120 B, first attempt).
Lever: the status word is masked by TWO separate statements (&= -3; &= -5;), and the original
emits one load, two ands against two different constants, one store. Combining the masks
folds to a single and and LOSES an instruction -- the same principle as finding 81 (a slot
stored twice is two statements) applied to read-modify-write. Companion: the status load is
hoisted above nine halfword clears, so the clears' source order is only observable through
the store order.
The first version of the fragment check fired on any nonzero sp offset and flagged 2 of the
555 registered regions. Worker B read its own hit (0x800B704C) before committing and showed
it is a LEGAL FRAMELESS LEAF WITH EIGHT ARGUMENTS: in o32 the callee's sp is unchanged at
entry, so sp+16..sp+28 IS the caller's outgoing area -- arguments 4-7 -- and reading it
before any addiu sp,sp,-N is exactly what a frameless >4-argument leaf looks like. Its
evidence: exactly one jr ra, zero jal, zero addiu sp,sp,-N, zero sw ra/lw ra across all 324
bytes, and no callee-saved register touched.
Excluding the incoming argument area (sp+0..sp+31) and flagging only a negative offset or an
offset beyond the 8-argument area makes the check DISJOINT:
registered regions flagged: 2 of 555 -> 0 of 555
suspects across 4 partitions: 5 -> 1
The one remaining suspect is worker A's 0x800C3490.
This is the cleanest example in the phase of a worker ADJUDICATING a tool's output rather
than obeying it -- B was explicitly told 'advisory, do not skip', read the row anyway, and
its adjudication turned a noisy heuristic into a precise one.
Worker A found 0x800C3490 is not a matchable body: it starts mid-expression with sw v0,32(sp)
before any frame setup, and its identical tail also appears at 0x800C3470, so it is a
shared/jump-target block Ghidra promoted to a function -- inside no region, with the code
before it in no worklist, so nobody can match it standalone.
Its generalised rule is narrower than 'first instruction is not prologue-like', because a
function may legally start with beq/sh/move: a row is a FRAGMENT if its first instruction
touches the stack before any addiu sp,sp,-N, reads a stack slot, or uses a callee-saved
register that is never saved.
Implemented as a --fragments scan. Measured: 5 suspects across all four partitions, but 2
false positives across the 555 REGISTERED regions, so it is ADVISORY not an exclusion --
sufficient-but-not-complete like the trapping check. A hit means read before spending a
spelling, never skip.
111: $sp cannot be moved from C, so a stack switch is INLINE ASM and the statement SPLIT is
byte-load-bearing -- seven separate __asm__ volatile statements with the call between them,
and the nop in each jal's delay slot falls out of the following statement being a compiler
barrier. One asm block, or a register int sp, does not reproduce it.
112: an intermediate that must live in MEMORY (the original reloads it before each of three
calls; a scalar local gets register-allocated and loses 8 bytes of frame); the chained
assignment's store order; and finding 100's then/else diagnostic confirmed on a new row.
113: a region's END address is EXCLUSIVE, so the registry free-check must be a containment
test, not a string match. Worker A was wrongly blocked on 0x8006B7C0 because it is the
exclusive end of 0x8006B778's range. This is the third defect found in a coordinator-written
rule this phase; the workflow doc now requires a range test.
Worker D's 0x800307FC (92 B) and 0x80031EBC (112 B), both first spelling by adjacency.
109 records worker D's calibration claim -- 'adjacency finds the ROW, redundancy predicts the
PRICE' -- and the harder discipline behind it: D read 0x8006C044, identified it as a
tie-break-dense 3D-maths routine, and RELEASED it in favour of two small adjacent rows that
together cost less context than a first draft and returned two bodies instead of zero-to-one.
110 records a NEGATIVE RESULT from the coordinator. Worker C found a real false positive (the
ranker's top row is tie-break-dense, its score inflated by a repeated multu/mflo/sra idiom)
and proposed comparing full instruction words instead of opcodes. I implemented that and
measured it: it scores two KNOWN matches at ZERO and the known false positive HIGHEST. The
reason is fatal -- a genuine repeated source block does not produce identical instruction
words across copies because the allocator assigns different registers, so 'same opcodes,
different operands' describes a repeated block and a repeated idiom equally well. They are
indistinguishable at the instruction level. The opcode metric stays.
Worker B's comparability caution: the redundancy score is the MAXIMUM of the 2/3/4-gram repeat
ratios, so a high score means 'some length scale is very repetitive', not 'repetitive at every
scale'. Any implementation using a mean or a different normalisation gives non-comparable
numbers, which matters because workers were sharing rankings across partitions. Pinned in the
tool's docstring with this tool named as the reference implementation.
107: finding 43's goto lever is NECESSARY BUT NOT SUFFICIENT -- worker B found it overshoots
(152 vs 140) on 0x800FCA90, and this is the second independent instance after worker A's
0x800256F0. Treat it as one attempt, not as the fix.
Worker A's 0x800914E4 (400 B), closed on the row assigned under the revised picking order
(adjacency first, then redundancy, preferring the smaller of similar-scored rows).
Records the full cycle: the 244 B ceiling was a dispatch artefact, ASPSX does not fill delay
slots (so the post-pass shrank from a modelling project to five lines), and the central finding
that cost is tie-break density rather than size -- measured independently by two workers from
opposite directions and now shared tooling.
Also records the four defects in coordinator work that workers found, the coordination defect
the best heuristic created, the new classes and levers (58-106), and two orchestrator notes:
the milestone counts BODIES not bytes, and a diagnostic should be routed to the row shape it
matches rather than broadcast.
Worker A appended three rows optimistically, classified them as near-matches, and then had
no way to clear them -- because the ledger was append-only with no terminal state. Every
other worker would have skipped three free rows.
Fixed: a status column (wip / released) where the effective state of an address is its LAST
row, and a rule that a worker must append 'released' when it stops. Worker A's three rows
are released.
The general lesson is recorded in the workflow doc: a write-ahead log needs a TERMINAL
state, not just an opening one, or the log itself becomes the stale data it was meant to
prevent. Any append-only coordination file needs a way to say done.
105: the pointer re-read granularity is a DIAL, measured in both directions by worker D --
re-read per store (700 B row, 46 times, matched), once per block (276 B row, matched),
per statement (80 bytes too long), and never (does not match). Cause is aliasing. It is the
same property as finding 45's named-locals family but as a COUNT rather than a yes/no.
Plus: a genuinely uninitialised read in the original must be preserved, not corrected.
106: which failure class a row lands in depends on the FILTER, not the band. Worker D's
cheap rows fail on frame/combiner/allocation/batch-shape and never on the branch
diagnostics, so those belong on tie-break-dense rows. Route a diagnostic to the row shape
it matches rather than broadcasting it.
The partitions had drifted: they still listed rows that have since merged, because make
worklist had not been re-run. Refiltered; every partition is now disjoint from the registry.
Promoted from worker B's staging implementation (which independently reproduced worker A's
metric). Ranks worklist rows by tie-break density: for n = 2/3/4, the fraction of
n-instruction opcode subsequences already seen earlier in the body, best of three, with
NOPS EXCLUDED (worker A's refinement -- lw/nop pairs otherwise inflate arithmetic rows).
This is the phase's central dispatch finding made reproducible. Evidence: worker A matched
548 B / 460 B / 356 B / 204 B all on the FIRST spelling while its one nine-attempt failure
was the SMALLEST row it attacked (176 B); worker D matched 1232 B on the 2nd spelling and
700 B on the 3rd while its 248 B row took 4. Cost is set by tie-break density, not size.
Companion rule (cookbook 99): once a row is matched, the row ADJACENT to it beats even the
top of this list -- the binary is laid out by translation unit, so neighbours share the
author's habits. 4-for-4 across two workers.
Worker A's 0x80033DC8 (360 B) and 0x8006A98C (132 B), plus two gp symbol rows
(D_80122724, D_80122728) that unblock 0x800A4CA8.
PROCESS DEFECT FOUND AND FIXED. Worker C and worker D both matched 0x800320D8
independently and D overwrote C's source file. Nothing corrupted -- both spellings match
and the region still reports 276/0/MATCH -- but one worker's effort was duplicated. The
partitions are genuinely disjoint (273/279/278/271, union 1101 = sum), so there was NO
assignment error: the gap was that no worker could know another had started a row, since
the registry only knows about MERGED claims and both started before either merged. The
root cause is the adjacency rule (cookbook 99, 4-for-4) crossing partition boundaries --
the best dispatch heuristic found so far invalidated the assumption the assignment rested on.
Fix: .run/p11/inflight.tsv (write-ahead log alongside the merge registry's commit log),
with the protocol written up in docs/ORCHESTRATOR_WORKFLOW.md so the next orchestrator
inherits it.
Worker A's 0x80068910 and worker B's 0x800FA5D8 -- the latter carrying the region token
maspsx=moves in column 4, which is the first use of the new mode through the real merge
flow. The token survived sf3_merge intact and the full 549-region gate is GREEN with the
mode active, so worker B's oracle-driven mode is now load-bearing on a registered region.
That closes the loop on worker B's ASPSX result: it ran all five SDK assemblers as a
read-only oracle, found ASPSX does not fill delay slots, concluded maspsx is faithful and
that the fills come from GNU as in reorder mode, identified move->addu as the only real
gap, and the resulting mode is now matching a region in the tracked registry.
Worker A's 0x800556E8 and 0x80055654 (both first/second attempt).
Cookbook 99 is a DISPATCH rule, not a codegen one: take the row ADJACENT to one you just
matched. The binary is laid out by translation unit, so neighbours share the author's habits.
3 for 3, all first or second attempt, and it beat both the size ranker and the LRS ranker.
Cookbook 100 puts the three branch-shaped diagnostics side by side -- each maps a residual
shape to exactly one cause and each is a glance rather than a spelling:
branch displacement words only -> block NESTING (95)
first few instructions, right length -> then/else ORDER of a single-statement arm
whole prologue, same multiset -> declaration vs assignment order
Vector copies are now confirmed on FIVE independent rows.
Worker A's two adjacent claims (0x80036B14, 0x80036DA4).
Cookbook 95 is the cleanest diagnostic of the phase: a correct-length candidate whose residual
is a handful of BRANCH WORDS means the block NESTING is wrong, not the code inside the blocks.
Worker A got exactly 656 bytes (correct length) with exactly 2 differing bytes, both branch
displacements, by writing two guards as siblings instead of nested. Residual = 2 bytes at a
branch displacement => go look at your braces.
Also: the project's 4-int vector type is identifiable from the frame (multiple of 16 with
offsets stepping by 16); vector copies are struct assignments (third independent confirmation);
and an OPEN question is recorded -- 'the original spills everything, cc1 promotes' -- with a
request for a recipe from any worker who has solved it.
Worker B's four first-attempt claims (0x800B255C, 0x8004857C, 0x80030858, 0x800909D8).
Cookbook 94 is the strategic one: worker B's failures cluster into exactly TWO mechanical
classes -- reorg slot-fill choice and rare-epilogue fill -- and neither is a shape problem.
Both are the post-pass family, which two workers have now independently arrived at and
stopped on. That is the strongest argument yet for writing the post-pass rather than
grinding these rows with source spellings.
Worker D's most transferable finding yet: the ADDRESS SYMBOL is what selects the addiu form.
A literal (int)0x8013F9B8 gives lui+ori; &D_8013F9B8 gives lui+addiu. So 'ori where the
original has addiu' means the source used a literal where it should reference the address
symbol -- a 40-byte error that presents as a LENGTH mismatch, which is why it reads like a
codegen problem. Extends findings 4/46.
90: a (gp)-relative access to an unregistered address is a SYMBOL REQUEST, not a source
problem -- the harness derives gp-ness only from config/symbols.tsv and no CLI option adds
it. Worker D verified its row by pointing --symbols at a scratch copy of the registry.
91: a real source-order quirk (two successive call addresses swapped) is preserved in a
match and is not a transcription error.
Worker A's 0x8009C904: 548 bytes, matched on the FIRST spelling. Cumulative evidence for the
redundancy ranker is now 548B/1st, 248B/3 spellings, 1232B/2, 700B/3 -- against 176B/9
failures for a tie-break-dense row.
Cookbook 87 is the important negative: cc1 does NOT unroll a constant-trip-count loop (the
for-loop form is 212 B against the original's 780 B), so whenever an original is unrolled the
SOURCE is unrolled too. That explains why the >800 B band is full of cheap rows -- those
bodies are unrolled in the source, and an unrolled repetitive body is exactly what the
ranker scores highest.
Worker B's 0x80069580 (88 B) and 0x8007E7FC (96 B), plus two gp symbol rows
(D_80122168, D_801221D0).
Cookbook 84 is the harness row for the post-pass: worker B isolated the rare-epilogue
transform exactly (move the frame release into the jump slot AND insert the load-delay nop
after lw ra), and established the load-bearing detail that as will NOT perform this fill
because doing so would put jr ra in the lw ra load-delay slot. So a post-pass that merely
moves the release into the slot produces wrong code. Also measured: maspsx=off is WORSE on
this row (72 bytes) because it strips nops from the beqz/jalr slots the original keeps, so
the two mechanisms are not substitutes.
85: cc1 folds SYM+N into a single la and SIX spellings do not defeat it.
86: cc1 cross-jumps identical guards; goto to a shared return label is the named lever.
Worker C's 0x800320D8 (276 B), matched on the FIRST spelling where its sibling 0x80031FC4
took 5 -- the family lever measured, on one family, both ways. Finding 55's limit confirmed
on the same family: a third row calling the same callee is NOT the same body and sits at
+16 instructions. The family transfers the derivation method and the stable positions,
never the body.
Also recorded: an OR nested inside an && chain is observable from the branch DIRECTIONS --
bne to the call block on one test and bnez to the manual-copy block on the other is
if (x == 0 && (a != 6 || b == 0)) call; else manual;
Worker D's 0x800910BC (280 B), its 8th match.
TWO CORRECTIONS TO THE COORDINATOR'S OWN COOKBOOK ENTRY, both from measurement:
- 67 was INCOMPLETE and cost worker D a spelling. The magic alone is AMBIGUOUS: D = 2^(32+s)/M
where s is the shift of the sra after the mfhi. 0x2AAAAAAB is /6 at s=0, /12 at s=1, /24 at
s=2, and worker D read it as /6 when the shift was 1. The corollary is worth having too: the
same magic twice in one function is not a contradiction (0x66666667 serves both /10 at s=2
and /5 at s=1, materialised once into a callee-saved register).
- The named-local rule is PER-SITE within one function. Naming a result the original consumes
immediately costs 2 words; naming one the original reuses is free. Apply the decision once
per VALUE, not once per function.
That is now the fourth correction to coordinator work this phase, and every one came from a
worker measuring something the coordinator had asserted.
Worker A built a repetitiveness score (repeated 2/3/4-instruction opcode subsequences,
normalised by body length) and produced the cleanest controlled comparison in the phase:
3 spellings on a 248 B repetitive row vs 9 failures on a 176 B tie-break-dense one. That
converts 'prefer a repetitive body' from a hunch into a sortable number, so size is
deprioritised as the ranking signal.
Also recorded: a transposed temp array is byte-required (int m[3][4] used as m[c][r]) with an
exact diagnostic -- right length + right instruction multiset + residual only on sp-relative
offsets means the frame LAYOUT is wrong, not the code; and when the original stores the same
slot twice, suspect two source statements rather than a scheduler quirk (GCC 2.7.2 has no DSE).
Worker C's 0x80031FC4 (276 B). Cookbook gains six entries, the most important of which is
worker C's correction of the COORDINATOR: a DEPENDENT row is one you cannot VERIFY, not one
you have MATCHED. C's 0x800A613C and 0x800FD120 had symbol rows outstanding, but
re-verifying against the tracked registry gave byte-identical results to the overlay runs --
both are still near-matches blocked on an ALLOCATION lever. Adding a symbol row unblocks the
verification, not the match; conflating the two would have had a worker stop working a row it
had not solved.
Also recorded: the address-taken value may be a PARAMETER not a local (frame 8 too big with
all offsets shifted by 8 is the tell); address-taken form forces a register; the struct
assignment is what BATCHES the loads where element stores serialise behind maspsx nops; and
the cop2 operand is the 25-bit field (0x486012 -> 0x4A486012).
+9 bodies: worker B's 0x8005E340, 0x8002C7EC, 0x800A8224, 0x8006B6BC, 0x80045F1C,
0x800F8A0C, 0x8002E9AC, 0x800196B4 and worker A's 0x800319F0 (whose dependent gp row
D_80122320 landed in the previous merge).
One new gp symbol row: D_801226E0 (append-only; the registry now has 395 rows).
Worker B's P1 band is finished: 10 rows, 5 matched, 4 near-matches with exact residuals,
1 blocked. THREE of the four near-misses failed on scheduling/allocation with the control
flow already EXACT, and one is a reorg slot-fill choice -- so that band's remaining yield
is in that class, not in shape work.
Two levers recorded from it:
- The address-taken value may be a PARAMETER, not a local. 0x80045F1C's frame is only 40
bytes yet it touches sp+56 and passes &a4 -- the FIFTH parameter, whose home is the
caller's outgoing-argument area at frame+16. Modelling it as a local reproduces the same
instruction SHAPE with a 48-byte frame and every offset +8 (22 differing bytes). So
'right shape, frame 8 too big, all offsets shifted by 8' => check for a parameter first.
- Address-taken form forces a register: 'int *p = &SYM;' gives la into a saved register
plus indirection, where reading the symbol directly gives the macro pair and no save.
Worker C's measured dispatch finding is the most useful strategic result of the phase:
across its 15 above-ceiling rows, 'does the body contain a repeated block?' has
out-performed 'how big is it?' SIX TO ZERO. Every one of its six matches is a
repetitive or mechanically-determined body (struct assignment, repeated identical
block, record initialiser, transposition, repeated bounds check); every one of its
nine near-misses is tie-break-dense (long straight-line call sequence, pointer-walk
loop, table walk). Worker D's rows say the same thing from the other side: its 700 B
and 1232 B bodies cost 3 and 2 spellings while its 248 B body cost 4.
Also confirms cookbook 44's stated limit directly: the && chain and eight separate
if(...) goto fail; statements compile IDENTICALLY here, so the distinguishing fact is
'one combined condition with one trailing assignment', not the operator.
+10 bodies in one gated pass from all three active workers: worker D's 0x8010AF50
(1232 B — the >800 B band broken on the FIRST attempt, in TWO spellings, 5.0x the old
244 B ceiling) and 0x80031BBC (260 B); worker C's 6 claims including the re-tested
0x800AFDBC which my nopmarker correction closed with NO source change; worker A's
0x8006B214 and 0x80027CA0.
Four gp symbol rows added (D_80122320, D_80121F2C, D_80122128, D_801226DC), APPEND-ONLY.
PROCESS BUG FOUND AND FIXED IN MY OWN FLOW: the merge chain piped the gate into grep and
chained with &&, which PROMOTED A DIFFED REGISTRY -- grep succeeds whenever it finds the
word 'result=' regardless of the verdict. Caught by the following make check (806734
differing bytes), reverted, and the registry restored from the last green commit. The
merge flow now lives in .run/p11/merge.sh, which gates on the gate's EXIT CODE and
refuses to promote on failure.
Worker D's recognition, which is worth more than the row: mult + mfhi + sra with NO mflo
is a CONSTANT DIVISION, not a 64-bit multiply. 0x4BDA12F7 is ceil(2^45/27648); a genuine
64-bit multiply emits mfhi AND mflo in every available cc1. Recover the divisor from the
magic as D = ceil(2^(32+s)/M), never from the constant's face value.
Records worker B's oracle result overturning the post-pass framing (ASPSX does not
fill delay slots; maspsx is faithful to it; the fills come from GNU as reorder mode and
the only gap is one mnemonic), the new `maspsx=moves` mode, worker C's correction of a
too-broad Phase 10 coordinator fix (now opt-in `maspsx=nopmarker`), the per-worker cost
tables that show SHAPE not band is the variable, and the new findings 63-66 plus the
named-locals family's fourth mechanism and the char[4] block-move recipe.
Committed at the orchestrator's 70% context cap; compaction follows, safe because the
ledger and CURRENT_PHASE are current.
Worker C found the defect while characterising an above-ceiling row: the Phase 10 fix
that made maspsx honour cc1's explicit `#nop` marker unconditionally is wrong for a
bare-symbol store consumer, because the store's own `lui $at` expansion fills the
delay slot and the marker is SPURIOUS. On 0x800AFDBC the original is
`lhu` / `lui at` / `sh` with NO nop, and honouring the marker costs 2 instructions --
turning a row that was otherwise byte-identical into a LENGTH-MISMATCH.
But the fix is genuinely needed for 0x80107C5C (112 vs 108). So the two rows want
opposite behaviour from the same instruction shape, and the honest resolution is to
make it a per-region mode rather than a global default.
`maspsx=nopmarker` -> --honour-nop-marker (default OFF)
VERIFIED BOTH WAYS:
make check with the mode OFF -> regions=510 AGREE, differing_bytes=0 MATCH, 253 tests OK
0x80107C5C WITH the mode -> 112 B, differing_bytes=0 MATCH
0x80107C5C WITHOUT it -> 108 B LENGTH-MISMATCH
So the default is the long-standing behaviour, and rows that need the marker opt in.
The tracked patch is regenerated and verified to reproduce both modified files exactly
from the pristine pinned checkout (tools/maspsx is git-ignored, so the patch is the only
reproducible carrier). docs/SETUP.md records the correction.
This is the third time this phase a worker found a defect in work the coordinator had
already shipped as verified -- the pattern is worth noting: a fix proven regression-free
against the CORPUS can still be wrong for an UNMATCHED row, because the corpus only
exercises the paths that already work.
+5 bodies: worker A claims 5-8 (0x800507A0, 0x80017B50, 0x800BBAC8, 0x800AFACC) and
worker D's 0x8006BC74 (700 B). Every candidate gate MATCH before promotion; all md5s
verified on disk.
*** 700 B IS THE LARGEST BODY EVER MATCHED IN THIS PROJECT *** — 175 instructions,
2.9x the old 244 B ceiling, and the FIRST match in the 401-800 B band. It cost THREE
spellings, fewer than worker D's own 248 B row (four). Both residuals were mechanical:
a missing `li 4096 / sw` pair hidden inside a run of 46 zero stores ("a run of repeated
stores is not a run of identical stores -- read every immediate"), and four extra
pointer reloads fixed by naming the sub-object pointer ONCE for the three byte stores
of 255 while leaving the fourth store its own re-read (cookbook 45's named-locals
family at its cheapest). Nothing about 700 bytes was hard: the body is large but highly
REDUNDANT, and redundancy is what a matcher keys off.
NEW HARNESS MODE `maspsx=moves` (worker B's oracle result, developer-authorized).
Worker B ran all five SDK assemblers (ASPSX 2.56/2.67/2.79/2.81/2.86) and every
supported option as a read-only oracle and found that **ASPSX does NOT fill delay slots
at all** -- it produces maspsx's exact shape. So maspsx is FAITHFUL to ASPSX, and the
fills in the original did not come from ASPSX. That overturns the "model ASPSX's fill"
framing: what fills the slots is GNU `as` in REORDER mode, i.e. maspsx OFF, and the only
real gap is ONE MNEMONIC -- `as` expands cc1's `move` to `or` where ASPSX emits `addu`.
So the mode is `maspsx=off` plus a single `move`->`addu` rewrite, letting `as` fill
exactly the slots cc1 left empty while cc1's own `.set noreorder` windows are preserved.
DEMONSTRATED: 0x800FA5D8 now reports 132 bytes / differing_bytes=0 MATCH where default
maspsx gives 148 LENGTH-MISMATCH. 7 new tests; suite 246 -> 253.
REGRESSION-VERIFIED: make check green at 510 regions / 253 tests with the mode OFF, so
every one of the 510 regions is byte-identical. The mode stays opt-in per region --
worker B measured the counterexample 0x8002D2BC, which has the SAME cc1 shape but whose
original keeps the store before the jr with a nop, so the original's assembler behaves
differently in different files.
Worker D's 0x8005A33C (312 B) and 0x8009F5AC (244 B) MATCH, both verified independently
and gated on the whole binary before promotion. Corpus max is now 312 B (244 -> 248 ->
264 -> 312 across two workers).
COOKBOOK 63 — NEW LEVER, the combiner constant-fold class. A residual of exactly one
addiu plus a matching shift in every displacement of one base register means cc1's
combiner folded a constant offset the original kept in a register. Writing the base
inline triggers it (308 B, one instruction short, 6 differing words all the same
thing); materialising the offset as a NAMED LOCAL blocks the fold and matches. It is a
4-byte class that is neither source structure nor scheduling, and it is INVISIBLE to a
mnemonic-level diff because every mnemonic is right.
COOKBOOK 64 — finding 59's family now has three load-bearing properties: row stride
(0x8009F6A0), total size (0x800308C4), and MEMORY RESIDENCE (0x8005A33C, where a union
lets cc1 scalarise the packed scratch into and/sra/sll).
COOKBOOK 65 — THE AMENDMENT TO FINDING 41 IS NOW MEASURED. Worker D ran the paired
control deliberately: the body immediately PRECEDING its first ceiling match, the
inverse transform with an identical frame shape. <=244 B: 1 attempted, 1 matched (100%),
first spelling. >244 B: 4 attempted, 3 matched (75%), 2-7 spellings. THE BAND WAS NOT
THE VARIABLE -- THE LEVER SET WAS. And the two LARGEST bodies were the EASIEST (312 B
and 264 B at 7 and 2 spellings), because a larger body has more redundant structure to
key off.
COOKBOOK 66 — a bounded negative with a named direction beats a blocked class: the
allocation failure on 0x800FF5A8 is the named-locals family in the OPPOSITE direction
(the original keeps a0 in TWO callee-saved registers, so what is missing is a named
local the allocator cannot coalesce).
494 bodies / 503 regions. Three bodies above the old 244 B ceiling from two workers
(248/248/264 B). Cookbook 59 extended with the unreferenced-array-local mechanism
(cc1 gives unreferenced scalars no home but does allocate for unreferenced arrays),
the amended three-direction rule, the per-band cost table, the sf3_merge fail-fast
fixes, and the rank-instability broadcast.
Worker D's 0x800308C4 (264 B) MATCHES, verified independently and gated on the whole
binary before promotion. Three bodies now sit above the old 244 B ceiling
(248/248/264 B) from two independent workers, so the dispatch-artefact verdict is
settled by result.
COOKBOOK 59 EXTENDED WITH A NEW MECHANISM. D's first attempt was 8 words from a match
and all eight were the FRAME; 56 of 64 words were already byte-identical including
every call site, delay slot and register. The missing 8 bytes are an UNREFERENCED
ARRAY LOCAL, and the mechanism is measured across five spellings: cc1 allocates stack
space for an unreferenced ARRAY local but NOT for an unreferenced SCALAR local
(`int pad0, pad1;` gives no home; `int pad[2]` and `short pad[4]` both match). The 8
bytes are size-load-bearing and content-free -- a limit of the reconstruction, not a
recovered fact, recorded as such in the file header.
AMENDED RULE: when the residual IS the frame, vary the local aggregate's declaration
in THREE directions -- element type, row stride, and total size. Instance 1
(0x8009F6A0) needed the row stride; instance 2 (0x800308C4) needed the total size.
+8 bodies: worker A claims 1-4 (0x8005E820, 0x80012DE8, 0x8001644C, 0x800A6880)
and worker C claims 1-4 (0x80048180, 0x800B107C, 0x80082868, 0x80036134).
Candidate gate MATCH before promotion; all 8 md5s matched on disk.
FOUR gp symbol rows added for 0x80017C6C (D_80121A2C/34/3C/44), coordinator-verified
against the payload: the original materialises them with addiu $2,gp,244/252/260/268.
C's claim 4 (0x80036134, 248 B) is the SECOND body above the old ceiling, matched on
lever-c-large row 1 — so two independent workers have now matched above 244 B, and the
dispatch-artefact verdict is confirmed by result rather than by inference.
sf3_merge format fixes, both triggered by real worker files:
- a bare header row is now rejected with "looks like a column HEADER" instead of a
confusing "not a hex address: 'start'"
- a lone `-` in the override column means "no overrides", matching the absent-value
convention the other tracked tables use
Suite 246 tests OK; make check green: regions=502 AGREE, differing_bytes=0 MATCH.
Finding 58 AMENDS finding 41, which was Phase 10's headline result and drove every
dispatch decision. The "1-in-12 for 200-800 B" comparison was taken on a queue that
had never been attempted (5 of 427 rows above 244 B ever tried, 1.2%; three in an
excluded class; both non-excluded attempts near-matched). The first row attempted
above the ceiling matched. The band's measured yield is a function of the lever set at
the time of measurement, and the lever set grows -- RE-MEASURE a band before
concluding it is exhausted, and never treat a band as closed at ~1% attempt coverage.
Findings 59-62: the local-aggregate row-stride/element-size lever that broke the
ceiling (int t[3][4] not int t[9]; frame 48 vs 40; residual concentrated on the frame
adjustment); the division_check trapped class; the localisation of the maspsx/GNU-as
mutual exclusion with the developer's ASPSX-as-oracle-only rule; and the fail-fast
validation of region override keys in sf3_merge.
Worker D's claim 0x8009F6A0..0x8009F798 (248 B) MATCHES. Verified independently by the
coordinator on a fresh work dir (candidate_bytes=248 differing_bytes=0 MATCH) and
gated on the whole binary before promotion. This is the FIRST body above 244 B ever
matched, and it sets a new corpus maximum (previous max 244 B at 0x80099078).
THE LEVER (worker D, 4 spellings): the local working buffer must be a 3x4 word array
(`int t[3][4]`, only columns 0..2 used), NOT `int t[9]`. The 4-WORD ROW STRIDE IS
BYTE-LOAD-BEARING: it moves the 2nd and 3rd triples to 0x10 and 0x20, makes the frame
48 B instead of 40 B, and leaves the unused 0x0C/0x1C slots the original shows. New
instance of cookbook 54 (a 2-D array's row stride is byte-load-bearing). The element
type is the other half: `short` locals let cc1 drop the sign extension (lhu/subu, no
frame); `int` locals keep it (lh/negu).
Diagnostic broadcast: correct length + right instruction multiset and order + residual
concentrated on the FRAME ADJUSTMENT and every sp-relative offset => suspect a local
aggregate's row stride / element size, not the control flow. D's variant (c) was a
textbook case: 19 differing bytes, all of them the frame size and the address shift
that follows from it, closed by one array-shape change.
Also in this commit — a fail-fast fix to sf3_merge. Worker D placed the source md5 in
the claim row's 4th column, which sf3_merge passed through as a region override, so the
row MERGED and only `sf3_match gate` failed later with "unknown override key 'md5'".
sf3_merge now validates override keys at merge time and rejects the row with a message
naming the valid keys and pointing at report.tsv for per-claim metadata. 4 new tests,
suite 242 -> 246, OK. The candidate gate caught it; the tracked registry was untouched.
Records: the "244-byte ceiling" is a DISPATCH ARTEFACT not a measured wall (5 of 427
rows ever attempted, 1.2%; three in an excluded class; both non-excluded attempts
near-matched; 84% unclassified ordinary code), so worker C is re-assigned above the
ceiling onto a 619-row dispatch file with 258 known-callee rows.
The new division_check exclusion class (break and div always co-occur; 0 of 493
registered regions contains either; worklist 1193 -> 1118).
Worker B's localisation of the maspsx/GNU-as mutual exclusion (ASPSX does both the
move->addu conversion and the fill; maspsx the first only, as the second only, and they
cannot be combined) with a 42-row/14% census in its partition, and the developer's
authorization of a tracked post-pass modelled on ASPSX's behaviour via oracle
characterisation -- ASPSX itself is a diagnostic oracle only, never a build stage,
because it is proprietary and git-ignored and a build depending on it could not be
reproduced.
Worker D's Goal B census found a second trapping-class-style blocker: `break` NEVER
appears without `div` and `div` NEVER appears without `break` -- 75 worklist rows,
0 exceptions. The shape is GCC's divmodsi4 with MASK_CHECK_ZERO_DIV|MASK_CHECK_RANGE_DIV
(div / bnez+break 7 zero check / li at,-1 + bne + lui at,0x8000 + bne quotient,at +
break 6 range check / mflo). `break` cannot be produced from C.
COORDINATOR-VERIFIED before implementing, as the project requires:
0 of 493 registered regions contains a div, a rem or a break (disjoint from corpus)
75 worklist rows have div+break; 0 div-only; 0 break-only (perfect correlation)
69 of the 75 are >244 B
Compiler matrix (worker D): every available cc1 either emits a BARE div with no check
(open 2.5.7-2.91.66-psx, and Sony CC1PSX 4.0-4.5, which reject -mcheck-zero-division),
or emits a check with a DIFFERENT shape (open 2.95.2-psx and CC1PSX 4.6: mflo before
the check, scratch $3/$4, comparing the DIVISOR against 0x80000000; the original
checks before mflo, uses $at, and compares the QUOTIENT). Not reproducible with this
toolchain -- the route is a cc1 build with those masks in TARGET_DEFAULT, which is a
developer-owned toolchain decision, not a source lever.
Implemented as `division_check` with a counted reason; excluded_division_check=81;
worklist 1193 -> 1118. 5 new tests, suite 237 -> 242, OK. make check green:
regions=493 AGREE, differing_bytes=0 MATCH.
Written at the developer's request after the control model changed from "the developer
spawns sessions" to "the orchestrator spawns, monitors and retires its own workers",
with pi-context-tools installed globally.
Covers: authority and what the orchestrator decides versus escalates; the herdr control
model with exact commands, the verified 2x2 topology, and the known failure modes
(including the transient agent_pane_not_found on a just-split pane, and the
mutual-ask intercom deadlock); the context model and the compaction-first policy with
the requirement it creates (state must live in files); roster sizing and the Goal A /
Goal B assignment split; the session lifecycle including the updated capability probe
with context_info; the hardened merge flow with the md5 drift guard; the verification
ladder; the full charter template; all nineteen process rules WITH THEIR PROVENANCE
(each earned by a real incident); and the phase open and close checklists.
Supersedes the session-management sections of PHASE8_PROTOCOL.md and PHASE9_PROTOCOL.md;
the merge/verification contract in those documents still stands.
Baseline revalidated at the Phase 10 close state: tracked maspsx patch applied,
make check exit 0, extents regions=493 AGREEE, gate differing_bytes=0 MATCH, 237
tests OK, 484 bodies / 493 regions, worklist 1193 with excluded_already_registered=493.
Roster spawned by the orchestrator via herdr (tab w1:t4, 2x2 at ~115x31); all four
probed clean and all four confirmed context_info + compact_context, which is the
basis for the compaction-first policy. Worker D is assigned GOAL B (the 244-byte
ceiling) with a bounded four-step investigation and a running GOALB.md deliverable;
A, B and C are on Goal A with 12-claim cycle targets.
Partitions: 4-way rank-interleaved, 299/298/298/298, disjoint, union == worklist,
near-identical tier/size mixes. Lever files rank size-band-first (cookbook 41):
P2 (<=200B, no lever) at 359 rows is the main target across the four partitions.
Charters carry the Phase 10 process rules as hard requirements: md5 per claim,
verify the staged path, cleanup audit before reporting, read ranges from the worklist
row, one attempt on a named lever then classify, fold region options into the claim row.
Plan approved by the developer with all four recommended decisions: milestone 600
(stretch 700), Goal B (the bounded 244-byte-ceiling investigation) in scope, a
4-worker roster spawned by the orchestrator with discretion to scale or retire, and
a compaction-first context policy.
Roster spawned by the orchestrator via herdr in a verified 2x2 grid (tab w1:t4,
~115x31 per pane):
w1:p5 worker-a 01a0d36a-be1f
w1:p6 worker-b 01a0d36b-1dc6
w1:p7 worker-c 01a0d36b-f346
w1:p8 worker-d 01a0d36c-02f4
All four probed; worker A confirmed context_info works (1.4% at spawn) and that
compact_context is available, which is the mechanical basis for the compaction-first
policy.
phase-ends/CURRENT_PHASE.md rewritten for Phase 11 with the planning finding (the
matched corpus median is 52 B, p90 108 B, max 244 B, and nothing larger has ever
matched), the roster table with herdr pane and intercom ids, the context policy, and
the carried machinery.
Prepared immediately after Phase 10 closure (484 bodies / 493 regions).
THE PLANNING FINDING THAT DEFINES THE PHASE: the matched corpus is n=493 with a
median of 52 bytes, p90 108 bytes and MAX 244 bytes -- NOT ONE BODY LARGER THAN 244
BYTES HAS EVER MATCHED. Against a remaining worklist of 1193 rows:
<=120 B 115 rows proven-matchable band
121-200 B 284 rows proven-matchable band
201-400 B 367 rows partially proven (up to 244 B)
401-800 B 245 rows UNPROVEN -- nothing has ever matched here
>800 B 182 rows UNPROVEN
So the ~400-450 rows at <=244 B are the finite proven band, and +116 bodies means
matching a quarter to a third of it. The 244-byte ceiling is therefore the real
subject, and the plan states TWO goals: A consume the proven band (the milestone
path), B break the 244-byte ceiling (a bounded investigation with a measured
deliverable, where a result that adds zero bodies is still a met goal).
Structural change: the orchestrator spawns and retires its own workers via herdr
(4 agent panes per tab, 2x2 verified at 115x31 each); the developer spawns only the
orchestrator. Context management changes too: pi-context-tools is installed
globally, so every session has context_info and compact_context -- measurement is
exact and self-service, and COMPACTION replaces rotation as the first response to a
full context, with rotation second. That is only safe because the state lives in
files, so keeping the ledger current becomes a hard requirement.
Four decisions requested: the milestone number; whether Goal B is in scope this
phase; the 4-worker default with orchestrator discretion to add a fifth; and
confirmation of the compaction-first policy.
MILESTONE MET AND EXCEEDED: 484 distinct matched bodies / 493 registered regions
(target 475, from the 400 baseline) — +84 bodies. Developer confirmation of the
milestone was requested and given before any close record was written.
Closing checklist all green from clean:
make clean && make all exit 0
cmp exit 0
SHA-1 both files e173426c157384ebf1b6caf8c6fea18a85a14af9
make test 237 tests, OK
make extents-verify regions=493 disagreements=0 AGREE
make gate c_regions=493 differing_bytes=0 MATCH
registry audit 493 rows, 0 overlaps, 0 unsorted, 0 bad extents,
0 missing sources, 484 distinct sources
worklist listed=1193, excluded_already_registered=493
negatives index 194 rows, address-ordered, 0 registered
git status --short src/ empty (0 untracked files)
firewall 0 prohibited-root paths (591 tracked files)
New records:
phase-ends/PhaseEnd_Phase10.md the phase record
docs/PHASE10_VERIFICATION.md the verification record
docs/MATCHING_COOKBOOK.md findings 41-57 (57 total)
phase-ends/CURRENT_PHASE.md CLOSED, with the checklist itemised
phase-ends/DIGEST.md the Phase 10 digest entry
The headline finding is methodological (finding 41, THE SIZE-BAND LAW): the matched
corpus median is 48 bytes with 454/459 at <=200 B while the remaining levered rows
had a median of 456 B, and two independent measurements — one controlled — put the
small band at 1-2 attempts per row against 1-in-12 for 200-800 B.
The phase's character: five of the coordinator's own generalisations were bounded by
workers (rare-epilogue class, register-field diagnostic, polarity lever, goto
trigger, load-delay consumer form). The rules that survived are the ones that were
bounded.
Five incidents recorded rather than smoothed over; the candidate gate rejected three
batches and the tracked registry was never corrupted. Scope held: the blocked classes
stay excluded, no scheduler-changing flag was granted, and inline asm was extended
only to shapes C provably cannot express.
STOPPING HERE. Phase 11 does not begin in this session.
+2 bodies (worker C2 claims 3-4). Candidate gate MATCH before promotion.
NEGATIVES EXTRACTION (the closing-checklist step that protects worker findings
from ignored staging being lost): imported 28 new negatives from all five workers'
staging into the tracked index, and dropped 28 rows that had since been REGISTERED
(the reconcile step working as designed). Index 166 -> 194 rows, address-ordered,
0 duplicates, 0 registered. Worklist 1193 rows; excluded_recorded_negative=170;
0 unregistered negatives survive into the worklist.
make check green: regions=493 AGREE, differing_bytes=0 MATCH, 237 tests OK.
Worker C2's cross-cutting finding recorded: three of its four negatives are the -O2
SCHEDULER, not source shape. For 0x800A6C34 (16 differing) and 0x80016F80 (45
differing), both at correct length, the identical source with
`cc1 -quiet -O2 -G0 -fno-schedule-insns` produces the original's instruction ORDER
byte-for-byte -- and both then show the same two-sided signature: sched OFF gives the
original's order but the wrong allocation (or the wrong delay slot), sched ON gives
the right allocation and the wrong order. Neither alone matches. C2 correctly did NOT
take the scheduler override (out of scope); both stay recorded as negatives with the
lever named. Diagnostic broadcast: correct length + a residual that is a permutation
of a few instructions + the unscheduled build matching the original order => the
residual is sched.
Also recorded: the commutative-operand lever has a COUPLED ALLOCATION side-effect
(0x80027744 at 4 bytes, 0x80050674 at 1 byte) -- every spelling giving the original's
addu operand order also flips which value takes v0 vs v1.
+2 bodies (worker C2 claims 1-2: 0x80051864 88 B, 0x8006AA10 120 B). Candidate
gate MATCH before promotion. make check green: regions=491 AGREE,
differing_bytes=0 MATCH, 237 tests OK.
C2 also confirmed the paired named-boolean rule exactly as broadcast (one shared
li a3,1 across four acceptance paths; nested ifs give two blocks and 124 B
LENGTH-MISMATCH; the single combined condition is byte-identical), and caught the
mask 0x00400000 vs 0x40000000 by computing the lui high half.
CROSS-CUTTING FINDING (worker C2, recorded for the cookbook): THREE of C2's four
negatives are the -O2 SCHEDULER, not source shape. Diagnostic: when the length is
exactly right and the residual is a permutation of a few instructions whose
-fno-schedule-insns build matches the original, stop hunting for a source shape.
Trap: on 0x80016F80 sched OFF gives the original's ORDER but the wrong allocation
while sched ON gives the right allocation and the wrong order, so neither alone
matches. C2 correctly did NOT take the scheduler override; all three stay recorded
as negatives with the lever named.
Also: the commutative-operand lever has a COUPLED ALLOCATION side-effect
(0x80027744, 0x80050674) -- every spelling giving the original's addu operand order
also flips which value takes v0 vs v1, because operand order changes pseudo creation
order. Finding 22's re-spell advice is necessary but not sufficient.
cc1 emits an explicit `#nop` marker when it wants a load-delay nop. maspsx used to
RE-DERIVE the need and could overrule cc1 for a BARE-SYMBOL STORE consumer:
uses_at('sw\t$2,D_801221C4') -> True (macro store, expands via $at)
uses_at('sw\t$2,0($4)') -> False (register+offset, no macro)
nop_at_expansion is False for ASPSX >= 2.30
so neither test in _handle_nop_before_next_instruction fired, nop_required stayed
False, and an instruction cc1 had explicitly asked for was dropped (0x80107C5C at
108 vs 112; worker B's 0x8003A9C8). The fix honours the marker instead of
overruling it; only that path changes.
Worker B2 found the gap but mis-diagnosed it: its proposed fix was to extend the
`line_loads_from_reg` predicate, which ALREADY returns True for a store source, so
that patch would have been a no-op. The coordinator traced the actual call and found
the real mechanism in the uses_at / nop_at_expansion interaction. B2 then appended a
CORRECTION row to its own staged report superseding its paragraph — the right
response, and it records the general lesson: a named mechanism is a hypothesis until
it is traced, even when the observation is solid and reproducible.
REGRESSION VERIFICATION (the whole point of gating this):
make check exit 0
regions=489 disagreements=0 AGREE
c_regions=489 differing_bytes=0 MATCH
237 tests OK
All 489 previously-matched regions are byte-identical with the fix in place.
Carried as a tracked patch (tools/maspsx/ is git-ignored, so an in-place edit would
not survive a fresh clone); patch verified to reproduce both modified files exactly
from the pristine pinned checkout. docs/SETUP.md records the fix and its provenance.
0x80107C5C NOW MATCHES (112 B, 0 differing, verified against worker B2's variant
X3.c) — but that is a BARE variant with no header, and the project convention requires
a documented source stating the observed instructions and limits. So the row is
UNBLOCKED and one documented source away, not claimed. Recorded as a carry-forward.
+6 bodies (worker A claims 23-26, worker B2 claims 8-9). Candidate gate MATCH
before every promotion.
FULL CLEAN AUDIT GREEN at the milestone:
make clean && make all exit 0
cmp exit 0
SHA-1 both files e173426c157384ebf1b6caf8c6fea18a85a14af9
registry 489 rows, 0 overlap, 0 unsorted, 0 bad extents,
0 missing sources, 480 distinct sources
firewall 0 tracked paths under any prohibited root (583 files)
suite 237 tests OK
The phase goal (475 from the 400 baseline) is met with 5 bodies to spare.
Per the plan, phase close requires the developer's explicit confirmation of the
milestone; this commit records the state, not the close.
SIZE-BAND FINDING now confirmed a third time, within-worker: worker B2's nine
matches cost 1, 4, 6, 4, 1, 2, 2, 1, 1 attempts -- the three <=120 B frameless leaves
all cost exactly ONE attempt, while the two >200 B P1 rows it opened with cost 6 and
4 attempts and produced ZERO matches.
Two more levers recorded from the closing rows:
- RECORD IDENTITY FROM WIDTHS (0x80041610): the two arms read three shorts at
+264/+266/+268 versus three ints at +20/+24/+28 through one extra indirection,
so they are TWO record types; declaring one shared type would have been wrong.
- a1[1] = -a1[1] RELOADS FROM MEMORY and its source order matters: the negation
reloads 4(a1) because the intervening store to 8(a1) may alias it.
- A 2-D ARRAY'S ROW STRIDE IS BYTE-LOAD-BEARING (0x800AC7A0): D[a3][a4] emits
sll a3,4 + sll a4,2 + add (correct length); D[a3*4 + a4] folds the outer *4 into
a second sll and comes out 4 bytes SHORT. When a scaled index is one sll short,
the source is a 2-D array, not a flattened index -- a LENGTH-class lever.
Christopher Williams