Static Recompilation Architecture

IMPLEMENTATION FACT + PUBLIC OVERVIEW · REVIEWED 17 AUG 2026

Executable input to portable host runtime

Static recompilation translates a known PSP executable into a host-native program while preserving guest-visible contracts. It is not a claim that every PSP binary is automatically portable.

Public pipeline

Each stage has a distinct responsibility and evidence boundary.

01 · INPUT

User-supplied ELF / PRX

Inspect lawful local input; retail content remains outside the public repository.

02 · IMAGE

Program representation

Model modules, segments, relocations, imports, NIDs, and guest address spans explicitly.

03 · ANALYSIS

CFG and ownership

Classify callable functions, interior entries, continuations, control flow, and fallback boundaries conservatively.

04 · TRANSLATION

IR and generated C

Lower Allegrex and VFPU operations against an explicit guest-state ABI, then emit chunked generated code.

05 · RUNTIME

Portable PSP semantics

Memory, scheduler, VFS, graphics, audio, input, and HLE services provide the host-side contracts.

06 · VERIFICATION

Evidence by class

Report source tests, synthetic fixtures, differential models, private routes, and physical PSP measurements separately.

Portable semantics versus host backends

Portable PSP-facing contracts

  • Guest memory and address validation
  • Imports, NIDs, HLE, waits, and callback semantics
  • Filesystem/VFS behavior and guest paths
  • GPU, audio, input, and timing semantics

Host/platform implementation

  • Files, process/tool invocation, and dynamic libraries
  • Threads, coroutines, clocks, and deadline waits
  • SDL windowing, input, and audio devices
  • Vulkan loading, surfaces, and presentation

Current host posture: Windows 11 x64 is first class for development and validation. Native Linux and macOS are future targets, not currently supported end to end. Win32 handles, fibers, drive letters, backslashes, and host clock details must not be described as PSP semantics.

Generated code and HLE boundaries

Generated output

Generated translation units are pipeline artifacts, not independent provenance. Entry and resume roles, callable functions, fallbacks, and dynamic chunking are derived from analysis and generator source; generated retail code is not committed.

HLE coverage

Imports map to explicit runtime services. Unknown or unimplemented NIDs remain visible; a stub or generic success handler must not be counted as a fully implemented PSP service.

The HST title profile currently selects -O2 for runtime code and -O1 for generated code. Those are optimized profile defaults, not universal settings; generic defaults remain distinct unless explicitly overridden.

Important boundaries

  • Software-renderer parity can localize a divergence; it is not an external PSP oracle.
  • A route that reaches gameplay is not proof of scheduler, callback, DMA, audio, or hardware fidelity.
  • Address-specific compatibility behavior is semantic debt and needs evidence, a regression, and a retirement criterion.

Current implementation

The public source of truth is Jstar269/nakagawa-recomp. Inspect current source, tests, Makefile, and maintained documentation before treating historical notes as current behavior.

Evidence class: this pipeline is an implementation overview; each subsystem page carries its own evidence labels.