The SLL instruction produced an incorrect result
kkHAIKE opened this issue · comments
Describe the bug
Expected behavior
$a1 should be 0x550 instead of 0xf0
Steps to reproduce the bug
Execute the MIPS code built with clang.
Operating System
MacOS sonoma
PCSX-Redux version
Version: 7460209
Changeset: 7460209
Date & time: 2023-12-30 04:01:58
CPU model
Apple M1
GPU model & Drivers
Apple M1
BIOS version
OpenBios
Options
- Dynarec CPU
- 8MB
- OpenGL GPU
- Fastboot
- Debugger
Iso checks
No response
Logs
No response
Additional information
The code builds into an executable that produces the correct result on my computer, but an odd issue is encountered when running it on pcsx-redus.
Are you sure the sll is actually executed right before the andi? The chances of sll being wrong are pretty slim since it passes tests and is a trivial operation, and if it didn't work properly nothing would work.
The running program is Twilight Syndrome, right? To check the code locally and all.
I checked, and it seems like the preceding IBU instruction might have a similar delay slot, causing $at to be set after the SLL finishes. clang must be build with load delay
If you're building mips I code, please do not use clang. Its support is incomplete at the moment, and it's indeed not supporting all the various hazard cases.
I checked, and it seems like the preceding IBU instruction might have a similar delay slot, causing $at to be set after the SLL finishes. clang must be build with load delay
In MIPS I (and not later versions) all memory loads + MFC/CFC have load delay slots and yeah LLVM doesn't fully support them (there's been some progress on it but I'm not sure if that's shipped yet). This means that not only will memory loads have a delay slot, but even reading a GTE register will have one.
Are there any recommended relatively modern compilers available now?
Stock gcc will do. See https://github.com/grumpycoders/pcsx-redux/blob/main/src/mips/psyqo/GETTING_STARTED.md