[ARMv6] vcvt instruction makes very un-human readable code

[f-raZ0R]

Probably related to #7377 , or the issue I can't find that had to do with multiple registers being used to store one value that is larger than a single register (an 8 byte length double when registers only hold 4 bytes)

Whenever I'm looking at some code that uses any variation of vcvt (e.g. vcvt.f32.s32), the decompiler ends up spitting out some nonsense involving bitshifts and "VectorSignedToFloat", and it's quite difficult to tell what is actually going on.
It would be nice if the decompiler... didn't do that, and instead did something more... understandable.

I've got 0 clue what this code here is doing, for example, beyond doing Something to calculate a percentage to display? (For context, fVar15 is a Constant that contains 100.0) in_fpscr isn't even a "real variable", it exists solely in vcvt calls and is probably some artifact of the decompiler.

[GhidorahRex]

in_fpscr is a variable that represents the fpscr register. Here it is specifically looking for the rounding mode which is why it's shifting it by 22 bits and masking it. The in_ prefix specifies that it's an unknown input parameter. Since the fpscr register isn't set in the code anywhere, it doesn't know where it came from.

I admit, it's a bit ugly, but it's still readable. vcvt converts a signed integer to a floating point value. So it is calculating a percentage, as you figured.

[GhidorahRex]

Part of the issue is that we don't have a good default value for fpscr. Looking at ARM documentation, it looks like the reset value of the register is 0x00040000. If you add a line to ARMt_v6.pspec to add this as a edefault value, and restart ghidra, I think it may fix your issue.

    <tracked_set space="ram">
      <set name="spsr" val="0"/>
      <set name="fpscr" val="0x00040000"/>
    </tracked_set>

[f-raZ0R]

Not really, all that does is replace in_fpscr with a variable that gets set to 0 at the start of the function, the bitshifts are still very ugly

[f-raZ0R]

The variable is a constant of 0 that doesn't get written to anywhere else, but the decompiler never optimizes the bitshifts out and just immediately gives the actual number? That feels weird

[GhidorahRex]

That's not what I see when I add that in. I would try clearing the bytes and re-disassembling that function maybe.

[f-raZ0R]

That didn't seem to fix it, did I not add it in correctly, or otherwise not clear it? I highlighted the entire function, pressed C, then D
Using options like Recreate Function or triggering a re-decompile don't correct it either.
ARMt_v6.pspec.txt

[GhidorahRex]

You added it correctly. I'm not sure why it is not showing up correctly for you, I'll try to play around with it more

[f-raZ0R]

Are you testing this on the latest commit, or in a release build? Was anything done to improve decompilation of bitshifts since the latest release? It's possible that it was already fixed and I just don't have the fix yet.

[GhidorahRex]

I am testing with the latest build, although I don't believe that should have any impact on it. It's most likely because of the environment. I've taken those bytes in isolation without any surrounding code and placed them in a dummy function in an empty binary I created.

The fact that the ghidra is assigning fpscr to a variable suggests to me that at least at some point it's changing the value of the register somewhere. Probably a vcmp instruction?

[f-raZ0R]

i'm looking at other uses of vcvct, and in some cases it's just directly a 0 (when the vcvt happens early on in the function), so i think you're right about some other instruction messing with it.
Trying to figure out what exactly is messing it up is difficult as there's usually quite a lot of code before the offending vcvt instruction.

A pattern I'm noticing is that every function that assigns fpscr to a variable has a vpush instruction near the start of the function, and the ones that don't and correctly simplify the bitshift, don't have a vpush. Could this be related?

[f-raZ0R]

Never mind, found a function with a vpush that doesn't mess up the vcvt. Huh