It was disabled because of issue 182, but as this game depeneds on FPRF, it was just 'fixed' because of the fallback to interpreter (which implements FPRF by default).
Also enables FPRF for this game via GameIni, so that the issue is still workaround.
If there are any regressions because of this commit, please try to enable FPRF in GameIni.
(Read_Opcode_JIT and Write_Opcode_JIT read/write from unrelated memory
areas.* Rename the latter and refactor.)
*except at the one specific exception handler where it doesn't. I
have no idea what this is supposed to do, but it probably doesn't do
it correctly. For now, remove the exception.
(1) The alternative doesn't compile.
(2) Despite "unlimited" sounding like a hack, it's actually
significantly more correct then the alternative, which is no
emulated icache.
(3) Easier to wrap my head around.
This implements a partial JITIL based off of the JIT64IL. It's enough to run most games, albiet at a slow speed.
Implementing instructions for this IL is really simple since it basically is just enabling based on what is already in JIT64IL, and then enabling each individual IL instruction.
It incorrectly continued to test EAX after it was changed to load
directly to the assigned register.
Also switch from a flush to ABI_PushRegistersAndAdjustStack, to avoid
needless flushing in the no-idle case.
And fix some stuff up. It would probably be good to unify the stack
handling some more rather than having ABI_PushRegistersAndAdjustStack do
part of it and ABI_AlignStack the rest, causing unnecessary subtract
instructions on Linux x86 (only).
As part of that, change SafeLoadToEAX to SafeLoadToReg, and have JitIL
use that, which should fix fastmem on JitIL.
This should also fix a potential stack corruption issue with x86.
It's extremely unsafe, unused (not exposed in the GUI and not present in
any gameconfigs), and mostly obviated by fastmem. Although this type of
thing could theoretically be useful someday for fastmem support with
MMU, it's probably not the best way to do it, the existing
implementation is way too simplistic, and it can always be dug up to
provide support for a new implementation if needed.
Not like it's a big deal to keep it working, but it really seems
pointless.
- Don't use %lu for size_t; they're different on Linux x86.
- has_warned_about_drivers is only used on win32, so only declare it
there to avoid a unused variable warning.
This properly fixes default gecko codes.
It makes perfect sense to have two separate cheat windows and two
separate code paths for the different code formats, right?
