Sometimes (in particular when using non-typesafe functions) it can be convenient to have a getter method rather than performing a potentially lengthy explicit cast.
This allows for removal of the strcpy calls, also it's technically way more safe, though I doubt we'll ever have a log name larger than 128 characters or a short description larger than 32 characters.
Also moved these assignments into the constructor's initializer list.
If a CPU string was incapable of being found we would return a null pointer, which would crash with strncpy.
Also if we couldn't get a CPU implementer we would call free() to a null pointer.
In addition, detect 64bit ARM running.
MemoryUtil.cpp was incorrectly using the old __x86_64__ define when it should be using _M_X86_64.
It was also using _ARCH_64 when it shouldn't have which was causing an errant PanicAlert to come up in my development.
Some compilers we care about (mostly g++) do not support std::make_unique yet,
but we still want to use it in our codebase to make unique_ptr code more
readable. This commit introduces an implementation derivated from the libc++
code in the Dolphin codebase so we can use it right now everywhere.
Adapted from delroth's pull request.
Set the x87 precision, even on x64. Since we are using x87 instructions
in the JIT now, we can't guarantee that x87 precision will never
influence Dolphin on x64.
The new NOP emitter breaks when called with a negative count. As it
turns out, it did happen when deoptimizing 8 bit MOVs because they are
only 4 bytes long and need no BSWAP.
Fixes issue 6990.
This uses a bit of templating to remove the duplicate code that is the CodeBlocks in each emitter headers.
No actual functionality change in this.
When creating a Fixupbranch we were swapping the BL and B targets.
I think this was found by PPSSPP a while ago, but they never send PRs to merge their changes upstream.
Between C++11 and C++14, volatile types stopped being trivially
copyable. The serializer has no reason to care about this distinction,
so tack on remove_volatile.
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
Tony Wasserka