Brian DegenhardtandClaude
14c8481277
The hand-rolled COP2 macro arithmetic ops re-emitted the same ~24-insn tail at every site: the ±FLT_MAX result clamp, the MAC/status flag extraction, and (at chain boundaries) the status denormalize/normalize bodies. These were the top three repeated instruction shapes in the UYA hot-block corpus — the largest single contributor to the EE hot-core emission-density gap vs the icache-friendly reference emitters, which generate this family once and BL to it (design adapted from neither/LRPS2's emitSharedVUBody, GPLv3, credit pstef). Seven stubs are emitted once per recompiler reset alongside the S4-2 sync stubs: two in-place clamps (q30/q31), three flag tails (mac+status / mac-only / status-only; xyzw dest mask in w1, result in q30 left clamped), and the status-chain denormalize/normalize pair. FMAC bodies now compute into RQSCRATCH and the per-site tail is a bare BL (flag-dead) or Mov-mask + BL (flag-live); operand pre-clamps are a Mov + BL. The flag stubs run the extraction with a single weight-vector load (new cop2Rec.macPackWeightsRev) instead of two literal-pool loads, and never clobber the result register, retiring the q28 park dance. The compute-into-cache-slot path (cop2ResultReg) stays for the tail-less ops; full-mask FMAC writes pay one Mov at the dest-mask apply in exchange. The denorm-in-w8 forwarding token is retired — the normalize stub always reloads (store-forwarded when adjacent). Flag semantics are unchanged: same clamp order, same lane math, same denorm-scratch RMW masks, same EP-4 chain gating. Pinned by the existing EeVu0Cop2MacroLazyStatus / cop2 macro suites (1389 tests green) and a UYA slot-02 stepdiff A/B (identical benign-only outcome vs base). Emitted-size A/B on the S4 hot set (same scene, same startpcs): -18.7% sample-weighted, COP2-dense physics blocks -30..-60%, whole shared corpus -5.5%. 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.