Brian Degenhardtandpstef
3d9afe72bc
A flag written but never READ still has to be finalised: mVUendProgram
stores it into VI[REG_MAC/STATUS/CLIP_FLAG], and COP2 reads those back on
VU0.
eBitPass1 already forced needExactMatch|=7 when the E-bit sat in the block
being compiled (State of Emergency 2, Driving Emotion Type-S), but
_mVUflagPass's forward scan hit an E-bit end and just broke out, marking
nothing - while the JR/JALR arm right beside it does force the bits. So a
block whose successor ends the program was told "the successor reads no
flags", and mVUsetFlags' forcing loop therefore never set mFLAG.doFlag: the
JIT emitted no flag writes at all. Finalisation then read a never-written
ring instance, because findFlagInst sees all-(-1) and falls back to slot 0.
Repro (a loop writing MAC 3x/iter, reading only STATUS, E-bit in the
fall-through block) finalised REG_MAC_FLAG as JIT=0x0 vs interp=0x24. Not
MAC-specific: the same hole dropped the low Z/S bits of STATUS (0xc0 vs
0xc3). Both VUs are affected - mVUdispatcherA reloads the ring from
VI[REG_*_FLAG] at program entry, so a stale instance left by one VU1
program is observable by the next one that reads MAC before writing it.
Fixed at both E-bit sites (eBitPass1 and the shortBranchPass lookahead) and
for both VUs, but not via needExactMatch, which upstream uses. That bit
does two jobs: it makes mVUsetFlags emit the tail flag writes (correctness),
and it persists into the successor's pState, forcing exact-match block
lookup and the mVUsetupFlags reorder at every link reaching a program end
(no correctness value). Instead:
- mVU.needFlagFinalize, compile-scoped, never enters pState, never
changes block identity.
- mVUsetFlags forces only the LAST tail FMAC's writes.
- getLastFlagInst recovers a flag the block never wrote from the incoming
ring phase - what the exact-match reorder had been implicitly providing.
Pre-existing and shared with upstream x86, whose _mVUflagPass has the
identical break. This diverges arm64 from the x86 JIT deliberately: x86's
behaviour here is a garbage-read of an unwritten ring slot, not a semantic
choice, so matching the interpreter (which agrees with real hardware) is
the correct call. The cheaper mechanism applies to x86 too.
Tests: new vu0_flag_link_reorder_tests.cpp - differential JIT-vs-interp
across an exact-match flag link. Against the unfixed tree these go 6 red
(both VU1 probes, both back-edge probes, the unconsumed-MAC finalisation,
and the delay-slot rotation) / 4 green; all 10 green after the fix. Also
adds vu1BranchToEbit, the first VU1 probe in the ABI-digest backstop: every
probe there compiled on VU0, so a VU1-only emitter change moved no digest.
Emitter shape change -> kMvuCompilerAbiVersion 14->15 (+ mirror + digest
row + the new VU1 pin). Full recompiler_tests 1352/1352.
Cherry-picked/reworked from pstef's yaps2 PR #7 onto our tree; digests
re-harvested on our base (spinLoop column kept as the 6th field, VU1 probe
added as the 7th).
Co-Authored-By: pstef <3462925+pstef@users.noreply.github.com>
yaps2
This is a fork of PCSX2 targeting ARM based linux handheld devices. We're aiming to be performant and compatible on lower end ARM hardware, and adopt a "by any means" philosophy.
Thanks
A massive thank you to the PCSX2 team for 20 years of dedication. yaps2 doesn't meet the rigor required of PCSX2 upstream commits, but maybe someday it will.
The following people worked on the yaps2 fork of this project:
- bmdhacks
- tokyovigilante
- pstef
FAQ
Is it good?
A: Yeah. It's pretty fast.
Where do I get builds of this software?
A: Builds are available in nightly releases of Rocknix and Batocera
Did you vibe code it? I see that claude authors your commits you cheater!
A: This fork was written by seasoned developers using LLM devleopment tools. Our philosophy is focused on results, not policing methodology, and modern LLM tools are the most effective way for us to reach our goals.
Can I contribute?
A: Sure. Send a PR. If it's vibe-coded trash we'll reject it. If it's good we'll use it.
Can I fork this project for my own purposes?
A: Sure. If you do cool stuff we'll probably use your code.
Don't you know about XYZ project that already does this
A: Yes we probably copied a lot of their techniques.
Can I make feature requests or tell you that I don't like what you're doing or how you're doing it?
A: Look, we're not trying to be a serious project here so no.
Can I make bug reports?
A: Absolutely, file a github issue and we might look at it.