There's some history for this instruction. It is not in the official
instruction documentations from AMD or Intel but it is supported on
almost every x87 supporting CPU (I think there was some Cyrix that
missed it?)
This was originally implemented by accident on the Intel 80287 CPU.
It was then periodically documented in random documentation.
The instruction behaves exactly like FFREE but then pops the stack after
the operation.
For our current implementation of FFREE, which is a NOP, we just need to
pop the stack.
This must of have been a copy and paste error, I didn't even have this
instruction on my list of implemented instructions.
It definitely isn't converting to a GPR
32bit apps are setting GS register that I saw.
64Bit applications can also technically use these instructions but it
has some major limitation that causes applications to never use them
These can only be implemented as acquire/release exclusive loops on
ARMv8.0 so they end up looking pretty disgusting.
This is more for compatibility for testing than anything. I'm not
expecting ANY ARMv8.0 device to get decent performance
This is just a virtual number that the guest can query through the
various means. Will affect mesa with how many helper threads it
generates at the very least
When the `BT mem` operation was accessing memory where the bit offset
wasn't a multiple of the access size, then we were dividing the offset
by bytes and accessing bits at `mem[byteOffset] &= (BitOffset)`.
BitOffset wasn't adjusted to compensate for the access size being added
to the address.
Causing a mismatch of testing the wrong bits. Unit tests didn't capture
this.
Trying to run glxgears on i965/iris showed extensive corruption because
of it though.
Theoretically the REP case can be optimized if it is known not to fault,
but that is one legitimate use case of this instruction.
This is just to ensure that we have this instruction covered, it hasn't
been encountered in a real program yet.
This implements support for 130 of the 132 x87 ops as interpreter
fallbacks.
The two missing ops are the BCD load and BCD store instructions and can
be implemented another time.
This allows us to no longer have to rely on a libstdc++ modification to
handle their usage of long double. This instead works entirely through
using `long double` directly in the interpreter. Which will either use
real x87 on an x86 host. Or in the case of ARM devices, fall down
glibc's long double soft float path.
This doesn't necessarily need to be quick right now. It's more important
to have the compatibility improvement from this.
