Merge pull request #33 from Tilka/readme

Readme: add link to issue tracker
Automatic translation template update
[VideoCommon] Eliminate the function Xchg in Statistics.cpp. std::swap does the same thing.
Merge pull request #35 from lioncash/videocommons-kill-xchg-in-statistics

[VideoCommon] Eliminate the function Xchg in Statistics.cpp. std::swap does the same thing.
Introduce a generic clamp function to clean up some similarly duplicated code.
Change the modified parameter in the Clamp function to be a pointer.

Makes it easier to identify the one being modified.
Merge pull request #36 from lioncash/generic-clamp-function

Introduce a generic clamp function to clean up some of the various 'if-else' clamps throughout parts of the codebase.
x64: add support for some x87 instructions
Jit64: fix float conversions

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.
Interpreter: fix float conversions

Can't use simple casting, otherwise we get the same problems as in Jit64.
Jit64IL: fix float conversions

Same procedure as in Jit64.
Re-enable non-IEEE mode support