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)
This fixes reserved RDP and CPU op-codes in Zelda MM due to wrong RDRAM address limitation calculations from the RSP. _WIN32 builds were not affected by this issue (due to the preprocessor disabling the analysis) and thus remain unaffected by this commit.
Although functionally there is no difference (when just looping vector elements from 0 to 7) between using a signed int or an unsigned int, repeatedly seeing an inconsistent mix in usage between the two across different vector functions has been an ongoing distraction for years. It should be the same everywhere, and between signed int and unsigned int, unsigned int is the type which always fits within size_t from stddef.h, the safe type for memory pointers and dereference indices.
When disabling ARCH_MIN_SSE2, the ANSI code path triggers several untraceable warnings that are nonsense (like integer union members giving warnings about pointer overflow). GCC purportedly has raised false positives with the overflow detection setting this high. Since it cannot give reliable reports in the ANSI code path for this RSP plugin (which does very little with what are actually pointers anyway in the vector unit), the level has been lowered down to 1.
Tracing the operands of an invalid LWC2 or SWC2 operation was just done to solve unused parameter warnings, which can be dodged without having to hack out a custom sprintf() replacement in the process.
This obfuscates the readable documentation of the SP_STATUS_REG bit resolutions in exchange for making it obvious how the bit patterns could be optimized (i.e., do all clears in one static operation and all sets in the next). As said optimization would result in further obfuscation in exchange for micro-optimizing an infrequent scalar unit system control command, said optimization will not be done in this file.
Explicitly linking in a dependency to libc allows us to analyze the dependency chain of rsp.so with `ldd ./rsp.so`. Without the C library linked in, the shared object will be reported falsely as "statically linked".
The original decision to use custom-tailored versions of the C standard
library functions for the Windows build came from a number of
issues--most of which turn out to be not applicable to a Windows DLL
module extension (in which no executable entry point is required).
Since most non-Visual-Studio build suites for Windows will use the
standard, universally available MSVCRT.DLL for linkage, no compatibility
issues can arise from switching the code back to use standard C calls
for _WIN32 builds (provided the calls and usages conform to ANSI C89 and
do not involve forwards-compatibility with other newer extensions to the
C language added in MSVCR80.DLL, MSVCR90.DLL and so forth).
Visual Studio itself, however, chooses to disallow targeting use of
MSVCRT.DLL because Microsoft changes the C language implementation
details of that file while promising the availability of certain
extensions and non-ANSI features available with fixed-version CRTS.
Therefore, if building with Visual Studio, this commit will cause a
dependency on some numbered version of Microsoft's CRT instead of the
standard MSVCRT.DLL.
Note that this issue is negligible due to the fact that MSVC cannot be
recommended for compiling an optimized interpreter code base (not
limited to the example of this plugin).
To test with MSVC anyway, either a) have the CRT framework package
installed to system upgrades (knowing end users the plugin is shared
with may not have this), b) use an older version of Visual Studio to
build, c) statically link the CRT dependency with /MT, d) use the
portable DDK suite containing MSVC outside of Visual Studio to continue
using MSVCRT.DLL, e) temporarily revert this commit to increase DLL file
size by using static linkage of the custom CRT functions removed by this
commit.
Another problem was the fact that MinGW GCC always links in CRT startup
code, even to DLLs for which no entry point needs to exist, and this
startup code depends on -lmingwex which adds a bit of custom message
crap to the binaries. The obvious workaround for this (as obvious as
knowing to do it for DLLs) in the case of an EXE was obfuscated by the
fact that MinGW maintains an arbitrary design choice that calls __main
from inside main instead of in the startup code. This side effect is
fixed by using preprocessor checks to wrap around a dummy __main symbol
in the entry point translation unit's source file.
If MinGW is installed to:
E:\MinGW\
...and the current directory is:
C:\Users\me\rsp\
Then `cd E:\MinGW\bin` is a null operation when the -D argument isn't
passed.
