概要
PSXRecompStudio の Recompiler を、すでに成立した 最小Vertical Slice / 最初のreal-ROM function proof から、実タイトル入力・coverage拡大・Runtime/Hardware統合・再現可能なtitle execution へ進めるための親Roadmap Issue。
今後の主要KPIは、proofの存在そのものではなく、どの実コードまで安全にrecompileできるか、どこで止まるか、Runtimeへどう接続するか、そして実タイトルの画面を実pipelineから再現できるかとする。
完了済みの基盤
Synthetic Vertical Slice — 完了
#209 で以下の最小経路を成立済み。
MIPS
-> validated IR
-> deterministic host C
-> host build
-> bounded execution
-> State Snapshot
-> Interpreter diff
First real-ROM function — 完了
#225 で、保守的に選択した実PS1 executable由来のbounded functionについて、real-ROM analysis → IR → host code → execute → interpreter comparison を成立済み。
これは「ゲーム全体がrecompile可能」という意味ではなく、実ROM由来コードをproof pathへ接続できることの確認。
Full-title execution orchestration — 基盤成立
#366 / PR #373 以降、segment単位のexecution orchestrationとstate continuityの基盤が存在する。
#380 / ADR-015 以降、production execution composition root が存在し、現時点のproduction pathは概ね:
Application entry point
-> TitleExecutionService
-> ExecutionOrchestrator
-> InterpreterTitleExecutionEngine
Real analyzed executable -> production execution — 完了
#409 / PR #425 で、legal user-supplied real PS-X EXE / disc analysis resultをproduction execution pathへ投入し、次のunsupported boundaryまでclassified executionできる経路が成立済み。
v0.1.0 方針 — CLI/headless first
#351 の Persona title-screen gateでは、Avalonia/Studio上のゲーム画面表示を必須にしない。
まず以下を実pipelineで再現可能にすることを優先する:
legal user input
-> analysis
-> recompilation / build
-> production Runtime
-> required BIOS/HLE + Hardware
-> GPU / framebuffer
-> deterministic frame capture (PNG/raw/hash)
-> CLI/headless verification
CLIは別のexecution/runtime実装を持たず、既存Application/Core/Runtimeサービスの薄いadapterとする (#15)。Studio GUIは同じframe/runtime境界を後から利用する。
このため、GUI project/workspace、解析画面、設定画面、ゲームframeのAvalonia presentationはv0.1のcritical pathから外す。
現在の最重要KPI
KPI 1 — Real executable enters the production path — 完了
user-supplied real PS-X EXE / disc analysis resultを、production title execution pathへ安全に投入できるか。
#409 / PR #425 で完了。
KPI 2 — Measure coverage, not only successful proof candidates
実タイトルの解析対象全体のうち、現在どこまでlower/recompile可能で、残りはなぜ拒否されるのかを説明できるか。
主対象: #410 / #215
KPI 3 — Explicit observable-effect semantics
MMIO / BIOS / runtime transfer / indirect control flow / exception-producing operationをordinary RAM/control-flowと混同せずfail-closedに扱えるか。
主対象: #411
KPI 4 — Runtime blockers are evidence-driven
実タイトル実行で遭遇した最初のunsupported boundaryを分類し、必要なCPU/BIOS/MMIO/Hardware supportだけをgenericに実装できるか。
主対象: #279 / #386 / #440 / #442 / #441 / 関連focused Issues
KPI 5 — Persona title-screen gate
#351 のrelease gateとして、Personaがfake/test-only pathではなく実pipelineでtitle screen frameを生成できるか。
GUI表示ではなく、CLI/headlessで実Runtimeが生成したframebuffer/frame evidenceを再現・検証できればv0.1 gateを満たせる。Core/RecompilerへのPersona固有hackは禁止。
現行ロードマップ
Phase A — Correctness / boundary hardening
原則: proof/test infrastructure自体が誤った結果を「一致」と判定しないことを先に守る。
Phase B — Real input -> production execution — 完了
Gate B: achieved. legal user-supplied real executableがproduction engineへ入り、実際のunsupported boundaryをclassified resultとして返せる。
Phase C — Recompiler coverage measurement
Gate C: 「選べば動く」だけでなく、「全体の何が動かず、なぜか」を再現可能に説明できる。
Phase D — Effect semantics / lowering safety
MMIO/device access、BIOS/runtime transfer、indirect/unresolved flow、exception-producing operation、unsupported effectをordinary guest RAM/control-flowと混同しない。
Gate D: 未対応effectはsilent loweringされず、明示的にunsupported/transferとして残る。
Phase E — Runtime / Hardware bring-up
実タイトルから得た依存グラフを根拠に進める。
主要scope:
GPU/SPU/CD-ROM/GTE等を番号順に全面実装せず、現在のreal execution blockerを前進させる最小generic scopeを優先する。
Phase F — Minimal first-class CLI
v0.1ではCLI全機能の完成を待たない。production executionを起動し、machine-readable outcome/diagnosticsを返し、#441のframe evidenceを保存/検証できる最小sliceを優先する。
CLIは既存Application/Core/Runtimeを再利用し、第二のruntime architectureを作らない。
Phase G — Dynamic / overlay code
static main EXE pathでoverlay/dynamic codeが実際のblockerになった時点で着手する。addressだけでなくcontent identityを基準にし、stale native mappingを実行しない。
Phase H — v0.1.0 title-screen evidence
成功条件:
legal user input
-> analysis
-> recomp/runtime pipeline
-> required BIOS/hardware services
-> GPU/framebuffer
-> deterministic captured title-screen frame
-> CLI/headless reproducible evidence
fake screenshot、test-only shortcut、title-specific Core hackは不可。Avalonia/Studio game-frame presentationはv0.1後でもよい。
継続して守るcontract
- Interpreter / differential referenceを使い、recompiled semanticsの変更を比較可能にする
- unsupported behaviorを推測で実装せずfail closedにする
- deterministic IR / generated source / analysis/frame evidenceを維持する
- copyrighted ROM/ISO/EXEをGitへコミットしない
- title-specific workaroundをgeneric Core/Recompilerへ埋め込まない
- coverage percentageとcorrectness proofを混同しない
- CPU semanticsを複数経路で独立再実装しない
- CLI/GUIはApplication/Core/Runtime semanticsを共有し、別々のruntimeを持たない
この親Issueの完了条件
Non-goals
- 最初から全MIPS I / 全PS1 hardwareを完成させること
- coverage percentageだけでcompatibilityを主張すること
- Persona固有コードをCoreへ追加すること
- dynamic overlay supportをstatic pathより先に完成させること
- v0.1 title-screen proofより先にStudio GUIを完成させること
- AI/GUI/Analyzer基盤拡張をRuntime/Recompilerの前進より優先すること
Related
概要
PSXRecompStudio の Recompiler を、すでに成立した 最小Vertical Slice / 最初のreal-ROM function proof から、実タイトル入力・coverage拡大・Runtime/Hardware統合・再現可能なtitle execution へ進めるための親Roadmap Issue。
今後の主要KPIは、proofの存在そのものではなく、どの実コードまで安全にrecompileできるか、どこで止まるか、Runtimeへどう接続するか、そして実タイトルの画面を実pipelineから再現できるかとする。
完了済みの基盤
Synthetic Vertical Slice — 完了
#209 で以下の最小経路を成立済み。
First real-ROM function — 完了
#225 で、保守的に選択した実PS1 executable由来のbounded functionについて、real-ROM analysis → IR → host code → execute → interpreter comparison を成立済み。
これは「ゲーム全体がrecompile可能」という意味ではなく、実ROM由来コードをproof pathへ接続できることの確認。
Full-title execution orchestration — 基盤成立
#366 / PR #373 以降、segment単位のexecution orchestrationとstate continuityの基盤が存在する。
#380 / ADR-015 以降、production execution composition root が存在し、現時点のproduction pathは概ね:
Real analyzed executable -> production execution — 完了
#409 / PR #425 で、legal user-supplied real PS-X EXE / disc analysis resultをproduction execution pathへ投入し、次のunsupported boundaryまでclassified executionできる経路が成立済み。
v0.1.0 方針 — CLI/headless first
#351 の Persona title-screen gateでは、Avalonia/Studio上のゲーム画面表示を必須にしない。
まず以下を実pipelineで再現可能にすることを優先する:
CLIは別のexecution/runtime実装を持たず、既存Application/Core/Runtimeサービスの薄いadapterとする (#15)。Studio GUIは同じframe/runtime境界を後から利用する。
このため、GUI project/workspace、解析画面、設定画面、ゲームframeのAvalonia presentationはv0.1のcritical pathから外す。
現在の最重要KPI
KPI 1 — Real executable enters the production path — 完了
#409 / PR #425 で完了。
KPI 2 — Measure coverage, not only successful proof candidates
主対象: #410 / #215
KPI 3 — Explicit observable-effect semantics
主対象: #411
KPI 4 — Runtime blockers are evidence-driven
主対象: #279 / #386 / #440 / #442 / #441 / 関連focused Issues
KPI 5 — Persona title-screen gate
GUI表示ではなく、CLI/headlessで実Runtimeが生成したframebuffer/frame evidenceを再現・検証できればv0.1 gateを満たせる。Core/RecompilerへのPersona固有hackは禁止。
現行ロードマップ
Phase A — Correctness / boundary hardening
原則: proof/test infrastructure自体が誤った結果を「一致」と判定しないことを先に守る。
Phase B — Real input -> production execution — 完了
Gate B: achieved. legal user-supplied real executableがproduction engineへ入り、実際のunsupported boundaryをclassified resultとして返せる。
Phase C — Recompiler coverage measurement
Gate C: 「選べば動く」だけでなく、「全体の何が動かず、なぜか」を再現可能に説明できる。
Phase D — Effect semantics / lowering safety
MMIO/device access、BIOS/runtime transfer、indirect/unresolved flow、exception-producing operation、unsupported effectをordinary guest RAM/control-flowと混同しない。
Gate D: 未対応effectはsilent loweringされず、明示的にunsupported/transferとして残る。
Phase E — Runtime / Hardware bring-up
実タイトルから得た依存グラフを根拠に進める。
主要scope:
GPU/SPU/CD-ROM/GTE等を番号順に全面実装せず、現在のreal execution blockerを前進させる最小generic scopeを優先する。
Phase F — Minimal first-class CLI
v0.1ではCLI全機能の完成を待たない。production executionを起動し、machine-readable outcome/diagnosticsを返し、#441のframe evidenceを保存/検証できる最小sliceを優先する。
CLIは既存Application/Core/Runtimeを再利用し、第二のruntime architectureを作らない。
Phase G — Dynamic / overlay code
static main EXE pathでoverlay/dynamic codeが実際のblockerになった時点で着手する。addressだけでなくcontent identityを基準にし、stale native mappingを実行しない。
Phase H — v0.1.0 title-screen evidence
成功条件:
fake screenshot、test-only shortcut、title-specific Core hackは不可。Avalonia/Studio game-frame presentationはv0.1後でもよい。
継続して守るcontract
この親Issueの完了条件
Non-goals
Related