This test fails with the non-JIT vertex loader due to an issue fixed in a later commit in this PR. (Note that the non-JIT vertex loader is only used on machines where no JIT is available or if COMPARE_VERTEXLOADERS is enabled in VertexLoaderBase.cpp.)
This is a little trick I came up with that lets us restructure our float
classification code so we can exit earlier when the float is normal,
which is the case more often than not.
First we shift left by 1 to get rid of the sign bit, and then we count
the number of leading sign bits. If the result is less than 10 (for
doubles) or 7 (for floats), the float is normal. This is because, if the
float isn't normal, the exponent is either all zeroes or all ones.
With this, situations where multiple arguments need to be moved
from multiple registers become easy to handle, and we also get
compile-time checking that the number of arguments is correct.
Using GTEST_SKIP instead of just returning from the function shows that
a test was skipped in the test summary. If GTEST_SKIP is called the rest
of the function won't be run, just like with the return.
GTEST_SKIP wasn't available until gtest 1.10, and we updated to 1.12 in
597f8f1b87.
Check bytes directly to avoid ambiguity in the disassembly between short
and near jumps, which could hypothetically cause the test to pass when
it shouldn't.
Replace the bool parameter force5bytes in J, JMP, and J_CC with an enum
class Jump::Short/Near. Many callers set that parameter to the literal
'true', which was unclear if you didn't already know what it did.
Now that we've flipped the C++20 switch, let's start making use of
the nice new <bit> header.
I'm planning on handling this move away from BitUtils.h incrementally
in a series of PRs. There may be a few functions remaining in
BitUtils.h by the end that C++20 doesn't have any equivalents for.
DataReader is generally jank - it has a start and end pointer, but the end pointer is generally not used, and all of the vertex loaders mostly bypassed it anyways.
Wrapper code (the vertex loaer test, as well as Fifo.cpp and OpcodeDecoding.cpp) still uses it, as does the software vertex loader (which is not a subclass of VertexLoader). These can probably be eliminated later.
This currently fails for direct with NormalIndex3 enabled (see https://bugs.dolphin-emu.org/issues/12952). The goal of this test is to be able to confidently say that that bug has been fixed.
We have one that does a similar thing, but only to measure speed and uses indices. This one verifies accuracy (and uses the largest possible input size by using direct components).
* moves dolphin-specific settings out of Base.props
* creates exports.props for externals, allowing to easily import
individual Externals
* corrects some cruft that accumulated and probably contributed
to msbuild overbuilding
Most of these correspond to changes made in devkitPro/libogc@b1b8ecab3a.
The numeric vlaues of ACC0 and ACC1 in Dolphin are different (see b06d38389b, though I'm not sure when this difference first appeared). Technically it's not even necessary to list the registers at the start like this anymore, but old programs do it, so it seems useful to have a test that covers it.
The binary itself does not need to be changed; the warnings were simply stating that "although you wrote $ACL0, the generated binary instead is using $ACC0" or similar; by changing the code to use $ACC0 directly the warnings are resolved.
I don't know what happened here, unfortunately. The version of dsp_mixer.s added to libogc on Nov 14, 2008 in c76d8b851f uses andcf and jlz here, and the version we have matches the one from Feb 5, 2009 in ae5c3a5fb5 exactly (prior to the fixes in my previous commit). I can't see any reason why wait_for_dsp_mail would be changed like this.
ANDCF and ANDF were previously swapped and JNE/JEQ/JZR/JNZ became JNZ/JZ/JLNZ/JLZ on Apr 3, 2009 in 7c4e654253, corresponding to a change Hermes made on Nov 10, 2008 in 2cea6d99ad. But these predate the test being added.
The only other information I can find is that ASNDLIB 1.0 released on November 11, 2008, at https://web.archive.org/web/20120326145022/http://www.entuwii.net/foro/viewtopic.php?f=6&t=87 (but there aren't any surviving links from there).
This change makes assembling DSPTestText match DSPTestBinary, though HermesText doesn't yet match HermesBinary.
The test data was originally added on April 18, 2009 in e7e4ef4481. Then, set16 and set40 were swapped on April 22, 2009 89178f411c, which updated the DSPSpy version of dsp_code, but not the version in DSPTool used for testing. So, when the test was made, the assembled data matched the text, but a few days after it no longer did.
Similarly, on Jul 7, 2009 in 1654c582ab the conditional instructions were adjusted, and 0x1706 was changed from JRL to JRNC and 0x0297 was changed from JGE to JC.
For what it's worth, devkitPro made the same changes on May 31, 2010 in 8a65c85c9b and updated their version of the asnd ucode (which is this ucode) on June 11, 2011 in b1b8ecab3a (though this update also includes other feature changes). Note that at the time, they didn't reassemble the ucode unless they made changes to it; the assembled was stored in the repo until bfb705fe16~...d20f9bdcfb43260c6c759f4fb98d724931443f93.
This fixes the following failures with Hermes:
!! 0015 : 8e00 vs 8f00 - set16 vs set40
!! 016f : 8e00 vs 8f00 - set16 vs set40
and with Hermes:
!! 0014 : 8e00 vs 8f00 - set16 vs set40
!! 0063 : 8e00 vs 8f00 - set16 vs set40
!! 019b : 1706 vs 1701 - jrnc $AR0 vs jrl $AR0
!! 01bf : 0297 vs 0290 - jc 0x01dc vs jge 0x01dc
!! 01d2 : 0297 vs 0290 - jc 0x01dc vs jge 0x01dc
Hermes has the remaining failures:
!! 027b : 03c0 vs 03a0 - andcf $AC1.M, #0x8000 vs andf $AC1.M, #0x8000
!! 027d : 029d vs 0294 - jlz 0x027a vs jnz 0x027a
Page faults should only occur on architectures that support exception
handlers, so skip the test on other architectures to avoid spurious test
failures.
SPDX standardizes how source code conveys its copyright and licensing
information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX
tags are adopted in many large projects, including things like the Linux
kernel.
