Weirdness with the Direct GR Operation Codetype

[biolizard89]

Here's my code:

CodeType Shift Test [biolizard89]
80000004 00000002 # GR4 = 0x2
80000005 00000002 # GR5 = 0x2
86700005 0000001F # GR5 rotate left by 31 bits (should be 0x1 now)
80000006 00000002 # GR6 = 0x2
86700006 0000001F # GR6 rotate left by 31 bits (should be 0x1 now)
86700006 0000001F # GR6 rotate left by 31 bits (should be 0x80000000 now)
80000007 00000002 # GR7 = 0x2
80000008 00000002 # GR8 = 0x2
86600008 00000001 # GR8 >>= 1 (should be 0x1 now)
80000009 00000002 # GR9 = 0x2
86600009 00000001 # GR9 >>= 1 (should be 0x1 now)
86600009 00000001 # GR9 >>= 1 (should be 0x0 now)

However, when I inspect the data in the memory viewer, I get the following:

GR4 == 0x2 (correct)
GR5 == 0x7C (should be 0x1)
GR6 == 0xF0000001 (should be 0x80000000)
GR7 == 0x2 (correct)
GR8 == 0x0 (should be 0x1)
GR9 == 0x1 (should be 0x0)

So it seems that the right-shift and rotate operations are not acting as I would expect them to.  Does anyone know why this would be happening?  Is there an undocumented behavior or bug of the GR Direct Operation codetype?

I'm on the 1931 handler.

Thanks!

EDIT: I ended up using an ASM C0 code to change the GR accordingly, which works perfectly fine.  Still, I'm curious why the GR codetype doesn't behave as expected.  Anyone know an explanation?

[dcx2]

I haven't looked too deeply, but I think the operands may be backwards.  That is, you think you're rotating 2 to the left 31 times, but in reality you're rotating 31 to the left 2 times.  That would explain the behavior you observe (0x1F becomes 0x7C)

[biolizard89]

I haven't looked too deeply, but I think the operands may be backwards.  That is, you think you're rotating 2 to the left 31 times, but in reality you're rotating 31 to the left 2 times.  That would explain the behavior you observe (0x1F becomes 0x7C)

Oh wow, I think you're right.  That would explain why only the shift operations are affected, since all the other available operations are commutative.  I'm assuming this is a bug and not a feature.  Okay, so I guess a workaround using GeckoOS codetypes would be to use an 88 codetype (which has the same issue) with the GR's reversed... and then move the result back to the correct GR, and restore the original value to the GR that got overwritten.  That sounds really ugly... is there a better way?  I might just stick with my C0 workaround if there's not a cleaner codetype workaround.

Thanks for the analysis!

[dcx2]

I'm not sure why you need to move GR's around?

If you aren't using e.g. GR15, then I would put e.g. 31 into GR15 and then use GR15 as the operand for shifting for all operations.  No need to move stuff around.