Emulator Issues #13374
open
JIT: paired singles instructions execute even when HID2.PSE is 0
0%
Description
What's the problem? Describe what went wrong.
The AMD64 and ARM64 JITs will execute paired singles instructions, even when they are disabled in HID2.
What steps will reproduce the problem?
- disable HID2.PSE
- execute a paired single instruction using the JIT
- observe the instruction is executed, and no illegal instruction exception is thrown
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
5.0-20211
Is the issue present in the latest stable version?
present in the latest beta (5.0-19870)
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
It's for an older master (I cloned the repo a few days ago and only had time to do something today), but there's a diff attached that fixes the issue for paired single load/store instructions in the AMD64 JIT, which I don't think is entirely correct (Broadway UM does say psq_lux/psq_lx/psq_stux/psq_stx does not check HID2.LSQE), yet should be useful as a starting point.
Files
Updated by JosJuice about 1 year ago
Unless this is needed for some specific game or homebrew, I'm reluctant to implement runtime checking of this, since it would affect performance. Your patch is doing compile-time checking, which is rather inaccurate.
Updated by pokechu22 about 1 year ago
Compile-time checking is fine if a JIT block is only used if the value of HID2.PSE matches the one it was compiled with, right? I think something like that is already done with address translation. It's probably not worth the overhead though.
I think the cached interpreter would also be affected as it re-uses the JIT infrastructure, just with a list of function pointers. The pure interpreter does check if paired single instructions are valid (in Interpreter::SingleStepInner).
Updated by JosJuice about 1 year ago
Compile-time checking is fine if a JIT block is only used if the value of HID2.PSE matches the one it was compiled with, right?
Yes, but we currently don't have any mechanism for ensuring that, unlike for address translation. Adding such a mechanism wouldn't be impossible, but it would require doubling the size of the fast lookup table. (Or quadrupling, if we want to track HID2.PSE and HID2.LSQE separately.)
Updated by Rairii about 1 year ago
The instruction cache is supposed to be invalidated after touching "any of the enable bits [in HID2]" (ppc_750cl.pdf page 66), and as far as I can tell JIT output is discarded on icache invalidation, so JIT compile-time checking may be accurate enough here?
Updated by Rairii about 1 year ago
Rairii wrote in #note-4:
The instruction cache is supposed to be invalidated by code after touching "any of the enable bits [in HID2]" (ppc_750cl.pdf page 66), and as far as I can tell JIT output is discarded on icache invalidation, so JIT compile-time checking may be accurate enough here?
Updated by Rairii about 1 year ago
(Sorry for the double post, I thought the quote button was an edit comment button. Not used to this bug tracker.)
Updated by JosJuice about 1 year ago
Maybe it would be good enough then. Do you have an example of any software that needs this behavior, homebrew included? I feel it's hard to reason about what's accurate enough without having something to test.
Updated by Rairii about 1 year ago
JosJuice wrote in #note-7:
Maybe it would be good enough then. Do you have an example of any software that needs this behavior, homebrew included? I feel it's hard to reason about what's accurate enough without having something to test.
I'm working on porting Windows NT 4 to the Wii.
All non-bytewise reads/writes are patched to an invalid instruction, to be emulated inside the program exception handler.
I use paired singles instructions for this purpose (as the Dolphin interpreter implemented the correct behaviour here, and I'm using Dolphin for debugging as I don't have an NDEV or similar).
The behaviour works on real hardware as expected, as does the Dolphin interpreter; and with a patch applied to implement the correct behaviour the JIT does too.
Updated by JosJuice about 1 year ago
Okay, then this kind of implementation sounds reasonable.
Personally I don't have time to work on this right now, but I would probably be interested in doing it at some later point, unless you want to implement it yourself before then.