If any operand is a signaling NaN, we need to signify this by setting
the VXSNAN bit.
Fixes NaN flag setting for fmsub, fmsubs, fnmsub, fnmsubs, ps_msub, and
ps_nmsub instructions.
If any operand is a signaling NaN, we need to signify this by setting
the VXSNAN bit.
Fixes NaN flag setting for fmadd, fmadds, fnmadd, fnmadds, ps_madd,
ps_nmadd, ps_madds0, and ps_madds1
If either operand is a signaling NaN, we need to signify this by setting
the VXSNAN bit.
This fixes NaN flag setting for fsub, fsubs, and ps_sub instructions.
If either operand is a signaling NaN, we need to signify that by setting
the VXSNAN bit.
This fixes NaN flag setting for fdiv, fdivs and ps_div instructions.
These aren't used to modify the data they point to, so make that
explicit. Also while we're at it, add const to any nearby variables that
can be made so.
This might happen if someone moves settings between e.g. a PC and
an Android device, or if someone was using JITIL and updates Dolphin.
I also made the panic alert a bit more explanatory.
It's not used anywhere other than in DolphinQt2, where the usage is
incorrect and stupid since we shouldn't be trying to stop the core
and 'restore config' that was changed by the core at app exit time,
but immediately when the core is being shut down.
Makes all of the naming consistent with our code style, and makes
parameters match their header equivalents.
Essentially just a clean-up of things that weren't migrated over
already.
If either of the operands are signaling NaNs, then an invalid operation
exception needs to be indicated within the FPSCR.
This corrects SNaN flag setting for fmul, fmuls, ps_mul, ps_muls0, and
ps_muls1.
In old GCC versions, capturing 'this' does not work for some lambdas.
The workaround is to not use auto for the parameter (even though the
type is obvious). This can be dropped once we require GCC 7.
If the input is a signaling NaN, then we need to signal that via setting
the FPSCR.VXSNAN bit. We also shouldn't update the FPRF flags if
FPSCR.VE is set.
If the FPSCR.VE bit is set and an invalid operand is passed in, then the FPRF
shouldn't be updated. Similarly this is also the case when the FPSCR.ZE bit
is set and negative or positive zero is passed in as the operand.
If FPSCR.ZE is set and a divide by zero exception is signaled, then the
FPRF shouldn't be updated with a result. Similarly, if the input is an
SNaN and FPSCR.VE is set, then the FPRF shouldn't be updated.
The VX bit is intended to be a summary bit indicating the occurrence of
any kind of invalid operation. Therefore, whenever an invalid operation
exception is set, also set VX.
This corrects our CR flag setting for multiple instructions in certain
scenarios. This corrects flag setting cases in fadd, fadds, fctiw, fctiwz, fdiv,
frsp, frsqrte, fsub, and fsubs (and technically every floating-point
instruction that we make more accurate in the future with regards to
flag setting).
This ports the Wii filesystem root, Wii SD card path and dump path
settings to the new config system (OnionConfig).
My initial plan was to wait until DolphinWX was removed before porting
most of the Main (Core, DSP, General) settings to onion config, but
I've decided to submit a small part of those changes to fix
[issue 10566](https://bugs.dolphin-emu.org/issues/10566).
Removes the need to manually set the FileUtil path in the UI frontends
and gets rid of some more members that don't really belong in SConfig.
Also fixes a bug which would cause the dump path not to get created
after change.
Only invoke config changed callbacks from Config::Save, not
Layer::Save. The latter results in callbacks being called
once per layer, up to 7 times per save.
These disc images are only used on dev units and not retail units.
There are two important differences compared to normal Wii disc images:
- The data starts 0x8000 bytes into each partition instead of 0x20000
- The data of a partition is stored unencrypted and contains no hashes
Our old implementation was just guesswork and doesn't work at all.
According to testing by GerbilSoft, this commit's implementation
is able to read and extract files in the filesystem correctly,
but the tested game still isn't able to boot. (It's thanks to their
info about unencrypted disc images that I was able to make this commit.)
Initialising Wii filesystem contents should be done after Boot and
not in HW to ensure that we operate with the correct title context
and to make sure required title directories exist (so that Movie and
Netplay code can copy data from and to the temporary NAND).
Previously, given cases such as 0x80000000 / 0xFFFFFFFF we'd incorrectly
set the destination register value to zero. If the dividend is negative,
then the destination should be set to -1 (0xFFFFFFFF), however if the
dividend is positive, then the destination should be set to 0.
Note that the 750CL documents state that:
"If an attempt is made to perform either of the divisions --
0x80000000 / -1 or <anything> / 0, then the contents of rD are
undefined, as are the contents of the LT, GT, and EQ bits of the CR0
field (if Rc = 1). In this case, if OE = 1 then OV is set."
So this is a particular behavior of the hardware itself.
Lioncash