ghidra
ghidra copied to clipboard
NationalSecurityAgency
Correct issue in 68000 sleigh
I'd like to provide my perspective on the root cause of this problem. As you've indicated, there is an inconsistent use of Dx/Dy in the reference manual, and it seems the SLEIGH spec was written assuming consistency. For instructions CMPM/ABCD/EXG/ADDX the register derived from bits 9-11 of the instruction is labelled as Dx, and the register derived from 0-2 is labelled as Dy. But for SBCD/PACK/UNPK/SUBX the labeling is swapped around. For each of these (except EXG) the assembly is consistently "MNEM src(0-2), dst(9-11)", so the behaviour is consistent but not the labeling.
In the SLEIGH specification, CMPM and EXG have been implemented separately, and PACK/UNPK are unimplemented, so this potentially only practically affects ABCD/SBCD/ADDX/SUBX. Currently the Tx/Ty tokens are consistent with ADDX/ABCD, derived from bits 9-11 and 0-2. Therefore, each instruction should use Tx as the destination and Ty as the source for both the display and the behaviour (pcode).
Prior to this suggested change, an assessment of each instruction is: · ADDX: this looks correct, as the pcode uses Tx as the destination, and the display is ordered Ty, Tx. · ABCD: the display looks correct, but the pcode uses Ty as the destination. · SUBX: the display and pcode look correct (but with labeling inconsistent with the manual). · SBCD: the display looks correct (but inconsistent with the manual), but the pcode uses Ty as the destination.
Therefore two changes are required: swapping Ty and Tx in the Pcode of ABCD and SBCD.
As your most recent update reflects exactly this for SBCD, I suggest just one more change to resolve the root cause: performing the same adjustment for ABCD.
@flk0 your analysis looks spot on. It would be helpful to add abcd to this same PR so we can close both at once.
@flk0 for what it's worth, #4223 adds PACK/UNPK - I had to switch operands' order around there as well.
@agatti Thanks. I have not tested this, but based on my previous comments I believe you need to amend your change by swapping X and Y, so that the second displayed register is the destination and is derived from bits 9-11. Again, this is caused by the inconsistent use of X and Y in the manual and the choice of X as the destination (bits 9-11) in the current SLEIGH implementation.
@flk0 indeed looks like you're right on that as well - I've updated the PR. Thanks!