Brian DegenhardtandClaude Fable 5
151b93fde9
The block scanner no longer ends a block at a forward conditional branch (BEQ/BNE/BLEZ/BGTZ/BLTZ/BGEZ; non-likely, non-link, non-BCx): it records a continuation site and keeps scanning at the fallthrough, so the not-taken path compiles as one straight line — no pc store, no event check, no linked-B, no next-head reload; register and constant residency ride through the former boundary. The taken arm becomes a cold side exit outlined after the block tail: it snapshots the compile state at the branch (BranchCompileState, per pending exit), and its emission restores the snapshot, compiles the taken-path delay slot (unless TrySwapDelaySlot already hoisted it), and ends with the normal SetBranchImm flush + event + linked-B tail. Compare shapes mirror recSetBranchEQ/recSetBranchL with the sense inverted (branch out when TAKEN), const fast paths included. Analysis stays exactly as conservative as today's block ends at each former boundary: the liveness backward pass merges all-live at the branch and its delay slot (the taken path leaves the block there), and the COP2 deferred-commit passes run per segment delimited at sites. A backward-split landing on a site's delay slot clamps to the branch instead (a split pair would leave the delay slot outside the analyzed range). Event-check coarsening equals today's straight-line blocks: one check per exit, range still capped by the 4K page. Caps: 8 sites, 128 insns per block. Composition with SL-01: loops whose body contains a forward conditional were previously split at it and could never form a self-loop — now they fuse into one block and the loop-residency preheader/back-edge applies (pinned by LoopWithInternalForwardBranchBecomesResident). Deliberate non-sites: backward branches (loops keep the SL-01 shape), likely variants (taken-only delay slot — different continuation shape), BEQ rs==rt (unconditional idiom), branch-class delay slots, compile-time const-resolved-taken. BNE rs==rt and const-resolved-not-taken continue with no side exit. Tests: ee_rec_superblock_tests (formation via recEeBlockGuestSize, both runtime paths vs interp, delay-slot-both-paths, dirty-state flush at taken exits incl. NEON quads, const propagation, multi-site, cap, SMC in the fused range, memory traffic across a site); full recompiler_tests 1336/1336. Co-Authored-By: Claude Fable 5 <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.