Drew T
f9742cf9c0
Fifteen tools each carried their own regex model of "what is a C declaration", and they
disagreed — two tools in ONE pipeline disagree today about whether `extern s32 D_a, D_b;`
is a declaration at all. All fifteen shared one character class,
extern\s+([A-Za-z_][\w\s\*]*?\bD_[0-9A-Fa-f]+\s*(?:\[\s*\])?)\s*;
which cannot hold '(', ',', or a non-empty [N] — so three whole shapes were invisible to
every one of them: fn-ptr/jump-table arrays, sized arrays (one unparsed `[4]` has blocked
func_801387B8 in 134 TUs), and multi-declarators (the WHOLE line dropped, not just #2..N).
REJECTED the audit's own prescription (a shape-aware alternation per tool, ~15 coordinated
regex edits) on R33 grounds: fifteen hand-maintained models are exactly what diverged, and
an alternation only ever covers the shapes somebody remembered. The thing being scanned HAS
A GRAMMAR. C's declarator grammar is small, closed and TOTAL — it describes fn-ptr arrays,
sized/2-D arrays, multi-declarators, fn-ptr params and K&R identifier-lists without being
told they exist. ~250 lines of recursive descent: LESS code than the regexes it deletes, and
exhaustive by construction rather than by memory. (decision-log 2026-07-14.)
Two statement paths, because the inputs genuinely differ:
* tu_statements() - a TU's file scope, derived from cpp. A decl inside a DEFINE_func_*
macro body declares NOTHING until the macro is invoked (the §8c law);
a raw scan is wrong in both directions. cpp answers it exactly, in
54 ms/TU (~20 s for the fleet, cacheable).
* split_statements() - span-preserving raw split, for drafts (which get rewritten).
THREE ORACLES, whole corpus — a measurement, not a belief:
* coverage 2,952,246 depth-0 statements -> 2,731,521 declarators, 0 PARSER DEFECTS
* the real gcc 50,405 distinct declarations compiled beside this parser's reconstruction
of each one -> 0 REJECTED
* differential 0 file-scope symbols the incumbents see that cdecl misses; 26 in
engine_core.h they cannot see; 6 they wrongly promote from BLOCK scope
Two ideas worth keeping (cookbook §51g, LAWS 4-8):
* THE CANDIDATE SET IS DERIVED TOO (R33 applied to R32). At file scope C admits nothing but
declarations, so R32's over-approximating detector is *every depth-0 statement* — supplied
by the grammar, with no hand-maintained candidate regex to rot.
* GCC ADJUDICATES MY OWN COVERAGE GAP. Deciding for myself which failures "don't count" is
grading my own homework — the habit that wrote the fifteen bugs. A statement gcc ALSO
rejects is not C (my rejection is correct, the INPUT is corrupt); one gcc ACCEPTS and I do
not is MY defect. All 33 residual: NOT-C, all dead .run/drafts* scratch, none in src/.
NEW findings (docs/tooling-audit.md):
* reconcile_decls.DATA_DECL_LINE_RE finds ZERO decls in engine_core.h — it is line-anchored
and every decl there ends in a '\'. Its "authoritative tier" has ALWAYS been empty.
* gen_harvest_targets + sig_unify count BLOCK-SCOPE externs (6, byte-proven inside a macro's
function body) as file-scope canonicals — the §8d `conflicting types` confusion.
* tu_ambient's func regex ([^()]* params) drops ANY callee with a fn-ptr parameter.
* R14 near-miss: 33 drafts contain `extern if ((func_80029178(0x119) & 0xFF) != 0);`, written
by a RECOVERY TOOL — but the source bug was already fixed in Phase 19 (0 garbage / 300 sigs
today). Mechanism confirmed, consequence nil. Note what it cost while live: a draft that
cannot compile fails the byte-gate and reads downstream as an INTRINSIC COMPILER WALL.
Bugs the oracles caught in ME (and would otherwise have shipped): `extern s32 (*D_801274D0)(s32);`
parsed the BASE TYPE as the name; a K&R declaration-list flushes as SEVERAL spans, so the body
attached to the wrong one and leaked the K&R parameter names into file scope as fake globals.
SCOPE, deliberate: NO consumer is migrated here, so this cannot move a byte. The audit warns
that making the parser see more ARMS dormant transforms (reconcile_decls.data_access_subs would
mangle `D_1[i]()` -> `((u8 *)D_1)[i]()` the moment fn-ptr decls become visible to it). Migration
is one tool at a time, each byte-gated.
R22 clean-fleet: make clean + extract-all + check-all -> 136 passed, 0 failed of 136
make audit-corpus: 0 PHANTOM + 0 TRUNCATED make audit-cdecl: ALL ORACLES GREEN (new gate)
BFM-decomp
A matching decompilation of Brave Fencer Musashi (PlayStation, SLUS-00726, USA 1998) — the first public decompilation effort for this game.
What "matching" means
The goal is C source code that, compiled with the original-era toolchain (PsyQ 4.x / GCC 2.7.2-family + ASPSX via maspsx), produces a byte-for-byte identical SLUS_007.26 and, eventually, byte-identical overlay binaries. SHA1 checksums are the ground truth; "functionally equivalent" does not count.
No ROM content
This repository contains no game assets, no disassembly output, and no ROM-derived data — only source code, build configuration, symbol names/addresses, hashes, and documentation. To build or contribute you must provide your own dump of the game disc (4-track BIN/CUE, redump layout). See .gitignore for the firewall.
Project status
Latest (Phase 19, 2026-06-20): the project builds 136 binaries byte-identical from a clean tree (the EXE + the resident engine + all 134 location overlays);
make check-all→ 136/136. Fleet byte-identical-from-source is 58.0% (function-instance-weighted; see the PhaseEnds for the byte-weighted ~30% figure and what it includes). Shared engine functions are matched once inov_SC01_077and propagated ×134 viatools/dedup_propagate.py. (The narrative below is Phase-11/12-era; a full refresh is part of the public-flip prep.)
Gen1 (foundation) complete — the matching pipeline is proven end-to-end. make extract && make build && make check rebuilds SLUS_007.26 byte-for-byte identical (SHA1 143dbb89…) from C + assembly, reproducibly across many sessions.
- Compiler pinned by evidence:
gcc-2.7.2-psx -O2 -G0 -mips1 -mcpu=3000+maspsx --aspsx-version=2.56 --expand-div. - 52 functions hand-matched to byte-identical machine code — including the LZSS streaming decompressor — with a decomp-permuter + matching-cookbook "flywheel" to accelerate the next.
- 959 PsyQ SDK functions linked byte-identical (libcd, libgs, libgte, libspu/libsnd, libgpu, libc2, libmcrd, libapi/libcard, libetc) straight from the real PsyQ 4.0 libraries instead of re-decompiling them — bringing byte-identical-from-source coverage of the EXE to ~50%.
- File-loader / overlay system reverse-engineered, with the resident engine blob + location overlays' load addresses proven byte-identical against a live PCSX-Redux RAM dump.
About half the EXE is still INCLUDE_ASM stubs (correct bytes, not yet C), and the bulk of the game lives in compressed overlays inside the .CD archives — Gen2 (overlays & engine at scale) is underway:
- The build toolchain is binary-agnostic (one parameterized pipeline builds any binary), and the always-resident engine blob rebuilds byte-for-byte from source (SHA1
8e17e02f…) — the second binary reconstructed exactly, after the EXE — and is now 86% hand-matched C (123 / 146 functions, up from 0): its scripting turned out to be compiled-MIPS state/mode dispatch, not a bytecode VM, and the save-file + sound (SQV) formats are documented. The harvest used a reusable swarm-of-agents + bit-for-bit byte-gate method (a wrong match can't be accepted) —tools/harvest_verify.py+tools/match_one.py, which carry straight into the overlay phase. - A cross-binary deduplication pipeline is live: a Ghidra-free signer fingerprints all 134 location overlays, and the report finds ~9,000 byte-identical function groups shared across binaries (~28 MB of collapsible code) — a single engine function is byte-identical in all 134 overlays. This is "one match unlocks many": each engine match will be auto-credited across the overlay fleet.
Current phase and detailed progress live in phase-ends/ (newest PhaseEnd_*.md = current state); methodology, rules, and the full roadmap are in PROJECT_CONTEXT.md; environment setup in docs/SETUP.md.
This project is developed primarily by Claude Code driving Ghidra through an MCP server; see CLAUDE.md.
License
Private repository for now. AGPL-3.0 is planned at public release, modeled on sotn-decomp. tools/brave-CUE/ is CUE's BRAVE extractor (GPL, source included) and retains its own license.