We can do this now that the x86-64 JIT supports PIE.
JITIL is deliberately excluded from the GUI because it
doesn't support PIE yet. (JITIL will be used if it's
set in the INI, though.)
instruction tables
Previously, all of the internals that handled how the instruction tables
are initialized were exposed externally. However, this can all be made
private to each CPU backend.
If each backend has an Init() function, then this is where the instruction
tables should be initialized, it shouldn't be the responsibility of
external code to ensure internal validity.
This allows for getting rid of all the table initialization shenanigans
within JitInterface and PPCTables.
This implements MIOS's PPC bootstrapping functionality, which enables
users to start a GameCube game from the Wii System Menu.
Because we aren't doing Starlet LLE (and don't have a boot1), we can
just jump to MIOS when the emulated software does an ES_LAUNCH or uses
ioctlv 0x25 to launch BC.
Note that the process is more complex on a real Wii and goes through
several more steps before getting to MIOS:
* The System Menu detects a GameCube disc and launches BC (1-100)
instead of the game. [Dolphin does this too.]
* BC, which is reportedly very similar to boot1, lowers the Hollywood
clock speed to the Flipper's and then launches boot2.
* boot2 sees the lowered clock speed and launches MIOS (1-101) instead
of the System Menu.
MIOS runs instead of IOS in GC mode and has an embedded GC IPL (which
is the code actually responsible for loading the disc game) and a PPC
bootstrap code. To get things working properly, we simply need to load
both to memory, then jump to the bootstrap code at 0x3400.
Obviously, because of the way this works, a real MIOS is required.
Makes it more obvious which data is going into the savestate.
It also allows PowerPCState and InstructionCache to potentially
contain members that don't necessarily need to be saved to the save state.
It also gets rid of any potential padding data being put into the save
state.
It wouldn't impact performance until at least one memcheck is enabled. Because of this, it can be used in release builds without much impact, the only thing that woudl change is the use of HasAny method instead of preprocessor conditionals. Since the perforamnce decrease comes right when the first memcheck is added and restored when the last is removed, it basically is all beneficial and works the same way.
For step over, it was updating twice which actually made the red display on the register view (when a register changes since) malfunction. Since it doesn't seem to be usefull to update before AND after the run, the one before the run was removed.
For step out, well, because there was no chances given for the thread to run as it is single stepping all the time, I only added a call to update after it was done.
Fix Frame Advance and FifoPlayer pause/unpause/stop.
CPU::EnableStepping is not atomic but is called from multiple threads
which races and leaves the system in a random state; also instruction
stepping was unstable, m_StepEvent had an almost random value because
of the dual purpose it served which could cause races where CPU::Run
would SingleStep when it was supposed to be sleeping.
FifoPlayer never FinishStateMove()d which was causing it to deadlock.
Rather than partially reimplementing CPU::Run, just use CPUCoreBase
and then call CPU::Run(). More DRY and less likely to have weird bugs
specific to the player (i.e the previous freezing on pause/stop).
Refactor PowerPC::state into CPU since it manages the state of the
CPU Thread which is controlled by CPU, not PowerPC. This simplifies
the architecture somewhat and eliminates races that can be caused by
calling PowerPC state functions directly instead of using CPU's
(because they bypassed the EnableStepping lock).
This affects enabling and disabling block profiling on the fly.
The block profiling pauses the CPU cores and then flushes the JIT's block cache and enables block profile.
The issue with this is that when we pause the CPU core, we don't have a way to tell if the JIT recompiler has actually left.
So if the secondary thread that is clearing the JIT block cache is too quick, it will clear the cache as a recompiler is still running that block that
has been cleared.
Change TMemCheck::Action to return whether to break rather than calling
PPCDebugInterface::BreakNow, as this simplified the implementation; then
remove said method, as that was its only caller. One "interface" method
down, many to go...
Updated PTE.R bit on Write and Instruction fetch.
Added code to read the PTE from MEM2 if the PTE is stored there.
Refactored the two hash functions to reduce code duplication.
Updated save state version.
This value was "helpful" for debugging when the stack got corrupted.
Helpful that if gpr[1](Which is the stack pointer with PPC ABI) is zero then the interpreter would spam huge amounts of annoy text saying that we
managed to get in to a "corrupted" state.
This is incremented every instruction on the interpreter, or every block run on the JIT64....Only if debugging is enabled(JIT64 it is a const
variable)
The message is only outputted when interpreter is used and debugging is enabled.
PowerPC has a 32 bit CR register, which is used to store flags for results of
computations. Most instructions have an optional bit that tells the CPU whether
the flags should be updated. This 32 bit register actually contains 8 sets of 4
flags: Summary Overflow (SO), Equals (EQ), Greater Than (GT), Less Than (LT).
These 8 sets are usually called CR0-CR7 and accessed independently. In the most
common operations, the flags are computed from the result of the operation in
the following fashion:
* EQ is set iff result == 0
* LT is set iff result < 0
* GT is set iff result > 0
* (Dolphin does not emulate SO)
While X86 architectures have a similar concept of flags, it is very difficult
to access the FLAGS register directly to translate its value to an equivalent
PowerPC value. With the current Dolphin implementation, updating a PPC CR
register requires CPU branching, which has a few performance issues: it uses
space in the BTB, and in the worst case (!GT, !LT, EQ) requires 2 branches not
taken.
After some brainstorming on IRC about how this could be improved, calc84maniac
figured out a neat trick that makes common CR operations way more efficient to
JIT on 64 bit X86 architectures. It relies on emulating each CRn bitfield with
a 64 bit register internally, whose value is the result of the operation from
which flags are updated, sign extended to 64 bits. Then, checking if a CR bit
is set can be done in the following way:
* EQ is set iff LOWER_32_BITS(cr_64b_val) == 0
* GT is set iff (s64)cr_64b_val > 0
* LT is set iff bit 62 of cr_64b_val is set
To take a few examples, if the result of an operation is:
* -1 (0xFFFFFFFFFFFFFFFF) -> lower 32 bits not 0 => !EQ
-> (s64)val (-1) is not > 0 => !GT
-> bit 62 is set => LT
!EQ, !GT, LT
* 0 (0x0000000000000000) -> lower 32 bits are 0 => EQ
-> (s64)val (0) is not > 0 => !GT
-> bit 62 is not set => !LT
EQ, !GT, !LT
* 1 (0x0000000000000001) -> lower 32 bits not 0 => !EQ
-> (s64)val (1) is > 0 => GT
-> bit 62 is not set => !LT
!EQ, GT, !LT
Sometimes we need to convert PPC CR values to these 64 bit values. The
following convention is used in this case:
* Bit 0 (LSB) is set iff !EQ
* Bit 62 is set iff LT
* Bit 63 is set iff !GT
* Bit 32 always set to disambiguize between EQ and GT
Some more examples:
* !EQ, GT, LT -> 0x4000000100000001 (!B63, B62, B32, B0)
-> lower 32 bits not 0 => !EQ
-> (s64)val is > 0 => GT
-> bit 62 is set => LT
* EQ, GT, !LT -> 0x0000000100000000
-> lower 32 bits are 0 => EQ
-> (s64)val is > 0 (note: B32) => GT
-> bit 62 is not set => !LT
This isn't a correct state for the CPU to begin in when starting the application.
Also CPU_STEPPING as an initial state causes the emulator to crash if you use any of the debugger stepping buttons, since it checks if the CPU is in the CPU_STEPPING state before performing their functions.
