Regarding changing parameter/return types of lqc2 instruction to float[4]

[jessep13]

The lqc2 and sqc2 instructions deal with an four-length array of floats. In the decompiled view of ghidra however, it treats these as some undefined type, and I wish to change the instructions themselves so that their parameter and return types are each float[4]. I have pictured below an example of my decompiled view to demonstrate the problem at hand.
If I do change the types of my parameters to be float[4] then ghidra instead creates a new variable still of undefined type to fit the instruction itself, which is unhelpful for tying to more accurately describe the type of this instruction. (see image below for result) Forgive me if this is some issue that can be resolved from ghidra itself instead of the extension, but since this instruction is related to the PS2 I'd figure it would be relevant to ask here for assistance.

[chaoticgd]

The lqc2 and sqc2 instructions deal with an four-length array of floats. In the decompiled view of ghidra however, it treats these as some undefined type, and I wish to change the instructions themselves so that their parameter and return types are each float[4]. I have pictured below an example of my decompiled view to demonstrate the problem at hand.

The lqc2 and sqc2 instructions are commonly used with floats, but not always, so I don't think it's reasonable to have the decompiler assume they're dealing with floats in all cases. It should however be possible to write a script to apply types in specific functions.

If I do change the types of my parameters to be float[4] then ghidra instead creates a new variable still of undefined type to fit the instruction itself, which is unhelpful for tying to more accurately describe the type of this instruction. (see image below for result)

I'm afraid I don't know enough about the internals of Ghidra's decompiler to know what's happening there exactly. I'm aware its current behavior with 128 bit types is sub-optimal but I am yet to find a good solution.

[chaoticgd]

It should be possible to do something like what you're suggesting, but on instructions that actually always operate on floats, such as vadd and vsub. You could write a script to do that. I forget if there's another way to do that.

Normally Ghidra's decompiler is able to infer these things using its pcode RTL, but my extension implements all the vector and MMI instructions as pcode op stubs. This is the way that the Ghidra developers seem to handle SIMD instructions in their own processor implementations too (see ARMneon.sinc and avx512.sinc).

The old beardypig version of the extension actually tried to implement these instructions in pcode, but I found it really didn't work very well in practice.

[chaoticgd]

If you want to have a go at modifying the SLEIGH spec yourself the relevant files are cop2.sinc and vuupper.sinc.

[jessep13]

The lqc2 and sqc2 instructions are commonly used with floats, but not always

I'm still new to reverse engineering PS2 itself, so is there any documentation on what the instructions available on the hardware? I've been struggling the last couple days on finding good resources available on that front, and having a more clear idea of what these instructions are would be much appreciated and may help clear my confusion as to the interpretation of the type in the decompiled view.

I'm still new to using Ghidra, so I'm probably not comfortable yet with scripting or trying to modify it to get what I need. I'll try to just work around this the best I can.

[chaoticgd]

The instructions are listed in the following manuals:

• EE Core Instruction Set Manual
• VU User's Manual