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.
Fundamentally, all this does is enforce the invariant that we always
translate effective addresses based on the current BAT registers and
page table before we do anything else with them.
This change can be logically divided into three parts. The first part is
creating a table to represent the current BAT state, and keeping it up to
date (PowerPC::IBATUpdated, PowerPC::DBATUpdated, etc.). This does
nothing by itself, but it's necessary for the other parts.
The second part (mostly in MMU.cpp) is simply removing all the hardcoded
checks for specific untranslated addresses, and consistently translating
addresses using the current BAT configuration. Very straightforward, but a
lot of code changes because we hardcoded assumptions all over the place.
The third part (mostly in Memmap.cpp) is making the fastmem arena reflect
the current BAT configuration. We do this by redoing the mapping (calling
memmap()) based on the BAT table whenever it changes.
One additional minor change is that translation can fail in two ways:
either the segment is a direct store segment, or page table lookup failed.
The difference doesn't usually matter, but the difference affects cache
instructions, like dcbz.
The PowerPC CPU has bits in MSR (DR and IR) which control whether
addresses are translated. We should respect these instead of mixing
physical addresses and translated addresses into the same address space.
This is mostly mass-renaming calls to memory accesses APIs from places
which expect address translation to use a different version from those
which do not expect address translation.
This does very little on its own, but it's the first step to a correct BAT
implementation.
Instead of passing the value around constantly, just store it in the regcache,
note where it is, and restore it on the exception path.
This saves a whole bunch of pushing and popping and gives a ~5% speed boost
in Rebel Strike. It's a bit ugly, but it simplifies a lot of code and is
faster, too.
Small TLB lookup optimizations: this is the hot path for MMU code, so try to
make it better.
Template the TLB lookup functions based on the lookup type (opcode, data,
no exception).
Clean up the Read/Write functions and make them more consistent.
Add an early-exit path for MMU accesses to ReadFromHardware/WriteToHardware.
Even in games that require MMU mode, loads outside the area specified by
the BAT are rare, so fastmem is a substantial improvement.
All of the interesting changes are in the backpatch handler, to make it
generate DSI exceptions correctly.
This is good hygiene, and also happens to be required to build Dolphin
using Clang modules.
(Under this setup, each header file becomes a module, and each #include
is automatically translated to a module import. Recursive includes
still leak through (by default), but modules are compiled independently,
and can't depend on defines or types having previously been set up. The
main reason to retrofit it onto Dolphin is compilation performance - no
more textual includes whatsoever, rather than putting a few blessed
common headers into a PCH. Unfortunately, I found multiple Clang bugs
while trying to build Dolphin this way, so it's not ready yet, but I can
start with this prerequisite.)
This time, check the address carefully beforehand, since apparently some games
do horrible things like running it on non-RAM addresses, or at the very least
virtual addresses.
Our defines were never clear between what meant 64bit or x86_64
This makes a clear cut between bitness and architecture.
This commit also has the side effect of bringing up aarch64 compiling support.
Design doc:
https://docs.google.com/document/d/11qcGCWLne1wYvmtFaSrOKZt_vHxXrcWcZsdWJ-MJnyo/edit
The code is currently not used. Migration plan:
1. Implement MMIO access via MMIO::Mapping in parallel to the current
method.
2. Implement all existing MMIO handlers via the new interface.
3. Remove the old hwRead/hwReadWii/hwReadIOBridge code.
4. Implement JIT optimizations for MMIO accesses.