Brian DegenhardtandClaude
47ec1b7d69
cop2FlushForConditionalSync freed EVERY in-use NEON register at every VPU_STAT-conditional sync seam, even though the C call sits behind the runtime check and is rarely taken — in the hottest UYA EE block (EE_003F7690, 16 seams) that meant a store->reload round-trip for the same GPR quads every ~6 guest instructions (61% of its q-loads reloaded same-block stores; the eejit ours-vs-aether snapshot pinned this as the flagship's density residual vs aether's whole-block NEON residency). Extend the S4-2 GPR/FPRC retention policy to the NEON file: - NEONTYPE_GPRREG quads / FPREG / FPACC are KEPT mapped with no writeback. The shared sync stubs blind-save the pool NEON file (q0-q7/q10-q24/q27/q28, 25 quads, full 128 bits) around the C calls on the TAKEN path only — state-agnostic, no per-site knowledge, and the 400 B of stack traffic sits on a path about to run a whole VU0 microprogram. q8/q9 need only their callee-saved low 64 bits; q25/q26 are re-materialized by the SL-13 Dups. - NEONTYPE_VFREG still frees WITH writeback (the VU0 micro writes VF, a retained mirror would go stale — same reason the VI mirrors free, and the EP-2b VF compile-cache flush stays). - TEMPs still free. Soundness is the S4-2 invariant: the sync callees (vu0SyncThin / vu0SyncRunAheadThin / _vu0FinishMicro / _vu0WaitMicro -> CpuVU0->Execute) never read or write EE GPR memory or fpr/fprc, so stale canonical memory during the call is unobservable; events raised by the micro are flagged and handled at block end, where dirty entries write back as today. M2 census (6000f UYA slot-02, identical 7644-block set, base = SL-13): flagship 3636 -> 3512 B (GPR-quad loads 78 -> 58), 003F7820 -6.3%, hot-90 sample-weighted bytes -1.8% — concentrated exactly where the SV-0 sizing said the class lives. Cumulative S5 vs pre-SL-13 base: hot-90 sample-weighted -7.7%, EE corpus -2.0%, clamp-const loads 8398 -> 0. Gates: 1404/1404 recompiler_tests (3 new EeVu0Cop2SeamSurvival tests: retention-filter policy probe, dirty-MMI-quad and FPREG riding a runtime-TAKEN seam); 8000-seed EE fuzz green; UYA slot-02 --stepdiff STEPDIFF output byte-identical to the SL-13 run (known-benign signature). Co-Authored-By: Claude <noreply@anthropic.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.