The underlying storage type of a bitfield can be any intrinsic integer type,
but also any enumeration.
Custom storage types are supported if the following things are defined on the storage type:
- casting 0 to the storage type
- bit shift operators (in both directions)
- bitwise & operator
- bitwise ~ operator
- std::make_unsigned specialization
Previously he function was misbehaving because of a missing check for
whether an 8-bit operand was a register operand; it would therefore
emit unnecessary REX prefixes, incorrectly assert on 32-bit targets, and
could potentially emit wrong code in rare cases (like a memory to register
operation involving AH.)
Also, some cleanup while I was in the area to make the function easier to
read.
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.
Breakpoints have one, but memchecks don't, despite being cleared directly in the breakpoint window.
Now DolphinWX should call the interface functions and not the direct functions of the breakpoints or memchecks for clearing.
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.
- 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
This breaks Linux stdout logging.
This reverts commit 7ac5b1f2f8, reversing
changes made to 9bc14012fc.
Revert "Merge pull request #77 from lioncash/remove-console"
This reverts commit 9bc14012fc, reversing
changes made to b18a33377d.
Conflicts:
Source/Core/Common/LogManager.cpp
Source/Core/DolphinWX/Frame.cpp
Source/Core/DolphinWX/FrameAui.cpp
Source/Core/DolphinWX/LogConfigWindow.cpp
Source/Core/DolphinWX/LogWindow.cpp
Note I do not mean the Logging window, but the console window.
It's literally rarely, if at all used, and offers less advantages over the built-in logging window (ie. it breaks on different locales: http://i.imgur.com/Cs92tQE.png)
This commit should remove all of the console logging.
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.
Pierre Bourdon
