The workaround of using fixed underlying types produces lots of warnings
in GCC because now the bit-fields are too small for the value range used
for conversion semantics.
- remove unused variables
- reduce the scope where it makes sense
- correct limits (did you know that strcat()'s last parameter does not
include the \0 that is always added?)
- set some free()'d pointers to NULL
- strip down PolarSSL's CMakeLists.txt
- switch to the PolarSSL 1.3 API
- use entropy interface instead of havege (PolarSSL 1.3 has disabled
havege by default because it is "considered unsafe for primary usage")
- add VS2013 .vcxproj file
I just removed Externals/polarssl/, added the new version, then deleted
the following files/directories:
DartConfiguration.tcl
Makefile
doxygen/
library/Makefile
programs/
scripts/
tests/
visualc/
This method doesn't involve messing around with the quirks of the x87
FPU and should be reasonably fast. As a bonus, it does the correct thing
for out-of-range doubles.
However, it is also a little slower and only benefits programs that rely
on undefined behavior so it is disabled for now.
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.
I give up. Merging the ppc_fp branch has caused issues in numerous games
and I can't find the bug. I'm leaving this merged to enable easy
recompilation for people who would like to play games that benefit from
non-IEEE mode emulation (e.g. Starfox Assault).
Revision ddaf29e039 introduced a register
corruption bug (#6825). Since fmrx/MOVSD only modifies ps0 but we save
both ps0 and ps1 in one xmm register, not loading the previous value
when binding to a x64 register trashed ps1.
But hey, a good opportunity to shave off one more instruction ;)
bDAZ is now called bFlushToZero to better reflect what it's actually
used for.
I decided not to support any hardware-based flush-to-zero on systems
that don't support this for both inputs _and_ outputs. It makes the code
cleaner and the intersection of CPUs that support SSE2 but not DAZ
should be very small.
Tillmann Karras