Closed Zinfidel closed 2 years ago
another nice enhancement would also be to decompile these to gte macros...
another nice enhancement would also be to decompile these to gte macros...
Definitely! I'm currently in the middle of a disassembly for the purpose of recompiling and I wouldn't need to reference the PSYQ headers constantly if it just resolved them in the decompiler.
I don't even understand how would I implement this.
In result I must provide my own mips processor implementation copy just to implement psx coprocessor specific functionality.
Implemented since: https://github.com/lab313ru/ghidra_psx_ldr/releases/tag/v6.0.
There are 6 store/load instructions for the GTE (
LWC2
,SWC2
,MTC2
,MFC2
,CTC2
, andCFC2
) that come in 3 forms:where
Notice that
gd
is a GTE data register (0-31) andgc
is a GTE control register (0-31). Using the plugin, Ghidra disassembles these instructions interpreting the first operands as either CPU registers or constant values, however. This leads to disassembly that looks like:MTC2
's second operand is listed as0x0
, where it should be the data registergd0
, which happens to be theVXY0
register. For theLWC2
command, thegd
operand is interpreted as CPU register 1 (at
) instead of GTE data register 1 (VZ0
).The decompiled code is similarly affected:
Here,
iVar1
andiVar8
just happen to be associated with CPU registers 0 and 1, and so they get placed in the function call incorrectly.Just a disclaimer, I'm a real novice with Ghidra so I'm not sure if this is a problem with the plugin, Ghidra itself, or just me!