Oh, even thought 2 months old merrymage rebased it 1 hour ago.
since you are the real JayFoxRox, when do you think subv's CROs are going to be rewritten and merged ?
I've already answered both of these (last time I'll answer to previously answered questions):
1. Merrys PR has been stuck in review and forgotten (I think), it has been outdated, I asked her to update it and we try to integrate it now before it is outdated again.
2. Nobody (not even Subv) knows. It's up to each developer how they spend their time.
I could just answer: "Tomorrow, 3PM GMT" and blame you if it's not done by then, because you have as many options as Subv and any other developer / user. Subv is not interested in working on it at this point.
Also all those Pokemon and CRO questions are really annoying, so it's understandable nobody wants to be pushed into doing CROs because there'd be a ton of people bugging you about it.
It does seem suspect that you would be developing a JIT Dynarec before you even have a reliable Interpreter engine.
If the Interpreter hasn't figured out every function necessary for games to be bootable and playable no matter how slow, the JIT Dynarec based upon that can't be accurate.
That's not true.
I've fixed 3 CPU bugs lately but the CPU was stable long before that too. With the new fixes it's even possible to run (all?) ffmpeg codecs (which are commonly used to test how good compilers are) and I'm not aware of any remaining issues with the CPU.
Also the interpeter we use is industry proven (parts of it are being used in Android and Linux).
However, the code is mostly ugly (= works but you don't really want to look at it) and there are tiny bugs which are hard to trace.
Even if there are bugs in the CPU they are usually not important. Mostly stuff like the CPU not reporting that the result of a calculation is not "exact". (`1.0 + 0.00000001 = 1.00000002` should trigger that the result is inexact for example, however, no game checks for that = not important)
Take everything of the following with a grain of salt (as I'm mostly working on the GPU emulation):
I think you are thinking of the incomplete kernel HLE which is independent of the CPU emulation.
- Most graphical issues boil down to bugs in the GPU emulation or the kernel <=> GPU interface (TextureCopy etc.).
- Most freezes, crashes etc. are caused by missing HLE (= missing kernel functions) or bad memory emulation (= kernel emulation is wrong), both of which can not be fixed by an interpreter / JIT.
- Maybe also freezes related to DSP emulation etc. but I'm not qualified to answer that
= not CPU related.