With the float instructions that only affect the lower 64bits of the destination register, we need to make sure to load the full 128bit register.
This ensures that we aren't saving garbage in to the top 64bits.
JitCommon is becoming a cluster of x86 specific things and things that are common to multiple recompilers.
This overlap is beginning to cause us issues.
Begin by breaking out the common ASM arrays to have their own file and move the x86 specific routines to their own folder.
For floating loads with a known address, this eliminates the pattern of:
mov r12d, 80001014
mov rdx, r12d
mov rdx, dword ptr [rbp+rdx]
and generates a nice simple:
mov rdx, dword ptr [rbp+00001014]
Instead of swaping each word of the elf code section(s) looking
for a match to our pattern, we swap the pattern just once (at
compile time) and test against our swapped pattern.
* Don't claim to support any features we don't, like relocation
* Actually zero-out BSS sections, as memory might not be already
zeroed.
* Deleted commented out code.
* Removed GetPointer, updated to more modern interface methods.
* Updated pointer types style from "u32 *x" to "u32* x"
* The file already exsists, otherwise we wouldn't have gotten
this far in the boot.
* We have already checked if it's a Wii or GameCube elf,
besides, it's too late to change our minds now anyway.
* On Wii - Don't call EmulatedBS2, it can never succeed as
it knows nothing about booting elfs. Just call the
SetupWiiMemory directly if needed.
* On GameCube - We still call EmulatedBS2_GC, but we stop
it from running Apploader, which might boot something
unexpected from the default iso or DVD root folder.
The Backpatching routines didn't correctly understand where to find the real VFP register from, so in most cases it was using D0.
Fixes bugs in the slowmem loadstore routines as well.
Instead of doing vector operations and throwing away the top 64bits of each operation, let's instead use scalar operations.
On Cortex-A57 this saves us three cycles per vector operation changed to scalar, so this saves 3-9cycles per instruction emulated.
Also puts one less micro-op in to the vector pipeline there.
On the Nvidia Denver I couldn't see any noticeable performance difference, but it's a quirky architecture so it may be noticing we are throwing away
the top bits anyway and optimizing it. The world may never know what's truly happening there.
