As explained within 179d73ac0d, the table
within the Programming Environments Manual for PowerPC lists the FI and
FR bits as cleared for invalid operation cases. So, we amend the
relevant cases here in order to be accurate to hardware.
As explained within commit a08ad82ace, if
an invalid exception occurs and VE is set, then the destination register
should remain unchanged. Ditto for when ZE is set and a zero divide
exception occurs.
This is only used internally, so we don't need to expose it in the
header. This also allows getting rid of inclusion of the byte swapping
utilities in the header as well.
Given they were only made public so that the callback could access class
state, we can simply make the callback a private static function of
CEXIMic, which allows access to members from the callback function
without making all of said members public.
In the PEM manual, within Table 3-12, which lists what should occur for
invalid operation exceptions, the FPSCR.FI and FPSCR.FR bits are listed
as "Cleared" for when FPSCR.VE is unset and set. So we clear these bits
as well to match hardware behavior.
In the PowerPC Microprocessor Family: The Programming Environments
Manual for 32 and 64-bit Microprocessors, in section 3.3.6.1, Table
3-12 lists what should occur if an invalid operation exception occurs in
situations where VE is set and when VE is not set. In the case where VE
is set, it lists the frD as "Unchanged". It also lists the FPRF flags as
"Unchanged".
Further down in Table 3-13, the listings for what should occur when zero
divide exceptions occur is listed, both for when ZE is set, and when it
isn't. When ZE is set, it lists frD as "Unchanged". It also lists the
FPRF flags as "Unchanged" as well.
This also alters the code so that we don't even calculate the result if
we don't need to compute it, making it a little bit less wasteful.
DataBinHeader is not used anywhere in the code other than via Header,
so let's merge them to reduce noise when accessing header fields
(currently we have to do header.hdr which looks silly).
It would make sense for 0x80 and 0xf0c0 to be respectively
sizeof(BkHeader) and sizeof(Header) as Nintendo is signing anything
that comes after the header, including the BkHeader.
