Known front-ends have been modified to save configuration after plugin
initialization but before running the game. Now it is no longer
necessary for individual plugins to save their config.
Removing calls to ConfigSaveSection from within plugins makes the
mupen64plus-ui-console '--nosaveoptions' parameter work.
I was unable to test complete operation with this patch, due to:
https://github.com/mupen64plus/mupen64plus-rsp-cxd4/issues/43
...but I was able to get past the plugin initialization phase, which
verifies that the code change works as desired.
Fixes#21.
In the face of all adversity to other sources indicating that the four-bit shuffling element specifier is recycled as a selector for the source element from VT, the only way to pass krom's hardware tests on the VMOV operation with operands illegal to standard RSP assembler was to replace this notion with the seemingly oversimplified read from `de` instead of `e`, even though that specifier is already in use as the selector for which destination slice to write to and not just read from.
Despite being removed from any references in the corresponding translation unit's functional implementation, the four-bit element shuffling mask is still in use as with all other vector operations for pre-shuffling VT[] before jumping into the vector operation interpreter function pointer table.
In addition, the MovIn register is also half-emulated. It is not maintained as a global state machine attribute and only stores the final, hardware-accurate result that was already going to be copied into VD[] anyway rather than the preconceived result of a direct copy from VT[e].
Fixes#19.
Disabling the optimized code is perhaps a temporary measure, but the more readable code under the #else clause should absolutely be kept. The optimized version for 2's complement machines has however also been patched with a fix in case it becomes desirable to go back to enabling it for substantial speed gains.
Sign-extension is correct but only for single-precision reciprocal calculations. Double-precision divides should still continue to mask in the zero-extended low 16 bits of the determined vector register slice if the previously executed divide instruction prepared a double-precision result rather than defining a single-precision one.
Not really a fix, just additional ifdefs to use the correct pointer
names for each case.
A proper fix would be to change the names in mupen64 api to fit the
upstream names or vice versa (considering the names I'd suggest the
former)
Not really a fix, but its done the same way in upstream for analog
uses.
Alternatively one could specify the size in the forward declaration of
the config object (in su.h)
