DSP LLE Recompiler: Fix LOOP and BLOOP when the counter is between 0x8001 and 0xFFFF #10723
+66
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
The loop ends when the counter reaches 0, and the counter is unsigned; before, it was doing a signed 16-bit comparison if the value was less than or equal to 0 after subtracting 1 from the value.
This wasn't caught by #10716 because the saturation results in a value of 0x7fff or 0x8000, neither of which trigger the bug.
I ran into this when investigating the CARD uCode, as it ends up using BLOOP with a counter set to 0xFFFF if the input length is set to 0. (This isn't something that happens in practice (as far as I can tell the input length is always 8 normally), nor is it behavior that seems intended, but it confused me because the interpreter and recompiler were giving different results.)