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.
While further increasing the table width doesn't make the code any less
ugly, it makes it easy to generate auto-comments in the IDA processor
plugin. Also, use spaces for alignment instead of tabs.
Floating-point is complicated...
Some background: Denormals are floats that are too close to zero to be
stored in a normalized way (their exponent would need more bits). Since
they are stored unnormalized, they are hard to work with, even in
hardware. That's why both PowerPC and SSE can be configured to operate
in faster but non-standard-conpliant modes in which these numbers are
simply rounded ('flushed') to zero.
Internally, we do the same as the PowerPC CPU and store all floats in
double format. This means that for loading and storing singles we need a
conversion. The PowerPC CPU does this in hardware. We previously did
this using CVTSS2SD/CVTSD2SS. Unfortunately, these instructions are
considered arithmetic and therefore flush denormals to zero if non-IEEE
mode is active. This normally wouldn't be a problem since the next
arithmetic floating-point instruction would do the same anyway but as it
turns out some games actually use floating-point instructions for
copying arbitrary data.
My idea for fixing this problem was to use x87 instructions since the
x87 FPU never supported flush-to-zero and thus doesn't mangle denormals.
However, there is one more problem to deal with: SNaNs are automatically
converted to QNaNs (by setting the most-significant bit of the
fraction). I opted to fix this by manually resetting the QNaN bit of all
values with all-1s exponent.
