Now that we fuzz against Unicorn, we aren't just restricted to VFPv2.
VFPv3 and VFPv4 facilities can now be implemented. This renames
constructs mentioning VFPv2 to just refer to VFP.
Introduces the same fuzzing mechanism used by the AArch64 code for
fuzzing instruction implementations, getting rid of the need to
manually specify the instruction generator sequences--replacing it with
an instruction blacklist instead.
Much of this change originates from a previous patch made by Mary. This
just makes it interact nicely with the alterations made to get Unicorn
to cooperate properly.
Now that we utilize C++17, we can use std::array's deduction guides to
avoid the need to explicitly specify the template arguments.
While we're at it, also use const where applicable.
This is quite a messy interpreter and would require a large amount of
work to bring it up to speed to begin implementing newer portions of the
AArch32 instruction set into Dynarmic.
Given we already have fuzzing with Unicorn set up for
AArch64/AArch32, we can get rid of this and unify our testing
infrastructure.
This will also make building the tests much faster, given a whole
interpreter doesn't need to be built anymore as part of the project.
While skyeye was OK previously, now that we have an AArch64 backend,
this also means that we eventually have to support the AArch32
counterpart to it. Unfortunately, SkyEye is only compatible up to
ARMv6K, so we woud need to do a lot of work to bring the interpreter up
to speed with things to even begin testing new instruction
implementations.
For the AArch64 side of things, we already use Unicorn, so we can toss
out SkyEye in favor of it instead.
MemoryRead8() takes a u32, but we were passing the result of a
u32 + size_t operation, which is 64-bit on 64-bit platforms. This
results in a truncation warning
* Return both the upper and lower parts of the multiply if required
* SSE2 does not support the pmuldq instruction, do sign correction to an unsigned result instead
* Improve port utilisation where possible (punpck instructions were a bottleneck)
enum classes are still considered complete types when forward declared
(as the compiler knows the exact size of the type from the declaration
alone). The only difference in this case being that the members of the
enum class aren't visible. Given we don't use the members within this
header in any way, we can simply forward declare them here and remove
the inclusions.
* The MSB for each byte in cpsr_ge were not being appropriately set.
* We also expand test coverage to test this case.
* We fix the disassembly of the MSR (imm) and MSR (reg) instructions as well.
x64 rounds before flushing to zero
AArch64 rounds after flushing to zero
This difference of behaviour is noticable if something would round to a smallest normalized number
