By default std::stack uses the heavyweight std::deque container for storage,
but std::vector is perfectly suitable for our purposes and it has better
performance characteristics.
Only the interpreter requires this currently since the stack register
doesn't match.
The JITs correctly set up their stack register and matches what the API
wants.
This is guaranteed to work. signal + rt_sigreturn is a handshake with
the kernel to return the data that the kernel wants.
Only time this doesn't align is when the guest signal handler longjumps
out of the signal handler. Which leaves a dangling entry in the
SignalFrame stack on the interpreter.
These are equivalent to the REX prefix's RXB bits, except that they're
in 1's complement form.
These are trivial to handle and fix usages of the upper range of
registers for ModRM encoded fields.
To ensure that we have coverage for this, I've altered the BEXTR test to
make use of R14 and R15.
In a syscall microbench this improves performance by ~19% on my
Snapdragon 888.
Going from ~9.6 million syscalls per second to ~11.5 million.
Macbook Pro is less effective here due to high syscall overhead due to
VM. Going form 7.2M/s to 7.6M/s, ~6% improvement
We can also inline some 32-bit syscalls but that will need some more
work which isn't done yet. Even though the op in the JIT supports it.
When the context structure is adjusted in the signal handler then this
updates the state of the CPU on sigreturn.
We check to see if the RIP was adjusted and in this case we will update
the JIT in a potentially unsafe fashion.
This works well enough with signal handlers that effectively just long
jump and not much else.
Fixes wine initial prefix setup where rundl32 expects to do a try-catch
fault capture but infinite loops without this.
CPUID lets the application know if it is running on a CPU with hybrid
CPU clusters.
This matches big.little fairly easily. Walk the affinity mask and
check if we are running on a big.little system and report it to the
guest.
For x86-64 host just pass through the flag.
We've run out of the range of 32 bits already and will need to use
another flag in upcoming changes, so we need to expand our flags to be
64-bit.
While we're at it, we can use a dedicated type alias for the instruction
flags to make the interface changeable from one spot in the future.
We can share this between the interpreter and the JIT. Necessary to
support the TSO-correct interpreter path.
With this change the interpreter is TSO-correct for GPRs. Just not FPRs
yet.
Ryan Houdek