Brian Degenhardt
f4debc54c1
The stale-overlap walk at the tail of recRecompile snapshots each
compiled block's guest bytes into recRAMCopy, then memcmps older
overlapping blocks against their own snapshots to catch code that went
stale through a write no protection path caught. recRAMCopy is a byte
array covering main RAM 1:1, but both the compare and the snapshot
indexed it at `startpc / 4`, packing every block's snapshot 4:1 into the
low quarter of the buffer.
Two blocks whose guest starts differ by N bytes then land only N/4 bytes
apart in the snapshot, so overlapping blocks scribble over each other's
snapshots and the compare can never match: each compile recClears the
other and both recompile forever.
Final Fantasy X (SLUS-20312) has such a pair at 0x002B9F48 / 0x002B9F5C.
Measured over 300 frames from an in-game savestate, EE thread:
before 56,546,855,007 insns 14,591,559,685 cycles 6 cache resets
after 5,885,593,412 insns 1,368,467,226 cycles 0 cache resets
9.6x fewer instructions, 10.7x fewer cycles. The EE thread had been
spending ~95% of itself inside the recompiler (vixl, register allocation,
vtlb_AddLoadStoreInfo, icache flushes) and only ~5% executing JIT code,
burning 51 MB of the 58 MB EE code cache every ~48 frames and taking a
full cache reset behind it.
The /4 was correct in 2009, when recRAMCopy was u32*. It became wrong in
d6de2e394 (2010), which swapped the storage to SpatialArrayReserve whose
operator[] yields u8&, and it survived every later refactor because both
index sites carried it consistently. Upstream x86 iR5900.cpp:2691/2701
still has it. The failure is conservative — it over-clears, never misses
a genuinely stale block — which is why it stayed invisible for this long
as a pure performance bug.
Also clamp the compare length so a block straddling the top of main RAM
cannot overread: correct indexing now actually reaches the top of the
buffer, where the /4 could never go.
recompiler_tests 1432/1432, including the three EeRecSmc overlap-walk
tests that pin this path. eerunner --stepdiff on FFX is unchanged before
and after (the pre-existing divergence at 0x002ce6d4 reproduces
identically on both).
ARMSX2 — Native ARM64 JIT Fork of PCSX2
ARMSX2 is a free and open-source PlayStation 2 (PS2) emulator based on PCSX2. Its purpose is to emulate the PS2's hardware, using a combination of MIPS CPU Interpreters, Recompilers and a Virtual Machine which manages hardware states and PS2 system memory. This allows you to play PS2 games on your phone, PC, or gaming handheld, with many additional features and benefits.
Thank You
The ARMSX2 team is eternally indebted to the PCSX2 project it is based on. We are so fortunate to build on their 20 years of hardcore development.
About This Fork
The upstream PCSX2 project ships an ARM64 interpreter build for ARM, but its high-performance JIT recompilers (EE, IOP, VU0, VU1, and vtlb fast memory) are x86-64 only.
This fork exists to close that gap. The goal is to preserve the correctness features of 20 years of PCSX2 development, while generating the fastest native ARM performance possible.
Current status:
- ✅ EE (Emotion Engine) recompiler — integer, float, MMI, COP0/COP1/COP2, branches, load/store
- ✅ IOP (I/O Processor / R3000A) recompiler — full integer, load/store, branches, coprocessors
- ✅ VU (Vector Unit) recompiler — microVU skeleton + Upper FMAC vector ISA complete; Lower ISA and runtime complete
- ✅ vtlb fast memory
- ✅ Native ARM64 binary builds and boots the PS2 BIOS
- ✅ 2D games are already playable
- ✅ 3D games run
Why LLMs / AI Were Used
A word on methodology:
The x86-64 JIT code in upstream ARMSX2 is already proven correct — it has run thousands of PS2 titles for years. The challenge in this port is not emulator design or JIT theory; it is mechanical translation of a large, well-understood x86-64 assembly codebase into equivalent ARM64 assembly (via VIXL) while preserving the exact same register-allocation contracts, block lifecycle, and recompiler semantics.
Large language models (LLMs) were used as an accelerant for this translation work — pattern-matching x86 JIT boilerplate to ARM64 equivalents, scaffolding emit routines, and keeping the porting velocity high. The JIT logic (block compiler, dispatcher, analysis passes, flag pipelines, clamping rules, Tri-Ace hacks, etc.) is taken directly from the upstream x86 implementation and validated against it. Nothing was hallucinated from scratch.
In other words: the hard engineering was done by the PCSX2 team over two decades. The hard typing — translating ~50k lines of x86 emitter code into ARM64 — is what AI helped compress.
System Requirements
ARMSX2 targets ARM64 across desktop (macOS, Windows, Linux) and mobile (Android, iOS/iPadOS), all from the single shared core. Our setup documentation page contains additional details on software and hardware requirements.
Please note that a BIOS dump from a legitimately-owned PS2 console is required to use the emulator. For more information, visit this page.
Building
Check out our github actions for the latest build recipe