A bunch of fixes for division logic:

"turns out theres a lot of quirks with the div instructions we havent been covering
if the denom is 0, we jump to the end and mov eax/rax to dst, which is correct because ppc raises no exceptions for divide by 0 unlike x86
except we don't initialize eax before that jump, so whatever garbage from the previous sequence that has been left in eax/rax is what the result of the instruction will be
and then in our constant folding, we don't do the same zero check in Value::Div, so if we constant folded the denom to 0 we will host crash
the ppc manual says the result for a division by 0 is undefined, but in reality it seems it is always 0
there are a few posts i saw from googling about it, and tests on my rgh gave me 0, but then another issue came up
and that is that we dont check for signed overflow in our division, so we raise an exception if guest code ever does (1<<signbit_pos) / -1
signed overflow in division also produces 0 on ppc
the last thing is that if src2 is constant we skip the 0 check for division
without checking if its nonzero
all weird, likely very rare edge cases, except for maybe the signed overflow division
chrispy — Today at 9:51 AM
oh yeah, and because the int members of constantvalue are all signed ints, we were actually doing signed division always with constant folding"

fixed an earlier mistake by me with the precision of fresx
made some optimization disableable

implemented vkpkx
fixed possible bugs with vsr/vsl constant folding
disabled the nice imul code for now, there was a bug with int64 version and i dont have time to check
started on multiplication/addition/subtraction/division identities
Removed optimized VSL implementation, it's going to have to be rewritten anyway
Added ppc_ctx_t to xboxkrnl shim for direct context access
started working on KeSaveFloatingPointState, re'ed most of it
Exposed some more state/functionality to the kernel for implementing lower level routines like the save/restore ones
Add cvar to re-enable incorrect mxcsr behavior if a user doesnt care and wants better cpu performance
Stubbed out more impossible sequences, replace mul_hi_i32 with a 64 bit multiply
This commit is contained in:
chss95cs@gmail.com
2022-08-07 10:41:26 -07:00
parent f45e9e5e9a
commit 324a8eb818
19 changed files with 512 additions and 477 deletions

View File

@@ -192,6 +192,21 @@ class ParamBase : public Param {
T value_;
};
class ContextParam : public Param {
public:
ContextParam() : Param(), ctx_(nullptr) {}
ContextParam(PPCContext* value) : Param(), ctx_(value) {}
ContextParam(Init& init) : Param(init), ctx_(init.ppc_context) {}
operator PPCContext*() const { return ctx_; }
PPCContext* value() const { return ctx_; }
PPCContext* operator->() const { return ctx_; }
protected:
PPCContext* ctx_;
};
class PointerParam : public ParamBase<uint32_t> {
public:
PointerParam(Init& init) : ParamBase(init) {
@@ -370,6 +385,7 @@ using int_result_t = shim::ResultBase<int32_t>;
using dword_result_t = shim::ResultBase<uint32_t>;
using pointer_result_t = shim::ResultBase<uint32_t>;
using X_HRESULT_result_t = shim::ResultBase<X_HRESULT>;
using ppc_context_t = shim::ContextParam;
// Exported from kernel_state.cc.
KernelState* kernel_state();
@@ -422,6 +438,9 @@ inline void AppendParam(StringBuffer* string_buffer, lpdouble_t param) {
string_buffer->AppendFormat("({:G})", param.value());
}
}
inline void AppendParam(StringBuffer* string_buffer, ppc_context_t param) {
string_buffer->Append("ContextArg");
}
inline void AppendParam(StringBuffer* string_buffer, lpstring_t param) {
string_buffer->AppendFormat("{:08X}", param.guest_address());
if (param) {