If I have a "C0" code with just a "mflr r4" like this:
RHAP01
WII Play
save lr
C0000000 00000001
7C8802A6 4E800020
then when I load the game it freezes (I haven't got my USB Gecko handy at the moment, so I don't know any more).
But if I replace it by a "mflr 3" it works:
RHAP01
WII Play
save lr
C0000000 00000001
7C6802A6 4E800020
(By "works" I mean it doesn't hang up. I realize the code doesn't do anything useful, I'm just trying to isolate the problem).
I haven't got a clue what's going on; can someone explain?
C0 codes run in the context of the code handler itself, rather than the game. It has quite a different set of rules regarding safe registers. Safe registers are also known to change between versions of the code handler.
Unfortunately, r4 isn't safe. IIRC, it's holding the line count for the C0 code, so that the code handler knows how many code lines
These two threads should prove helpful for you.
http://wiird.l0nk.org/forum/index.php?topic=1733.0
http://wiird.l0nk.org/forum/index.php/topic,5622.msg55892.html#msg55892
EDIT:
oh yeah, the safety of some of the non-volatiles above r13 can change depending on whether the debugger is being used or not. lol
Quote from: dcx2 on August 07, 2011, 01:31:01 AM
It has quite a different set of rules regarding safe registers.
Thanks - sounds kind of obvious now you've pointed it out. I saw the generated code had a
blr added so for some reason I assumed a stack frame had already been set up. I forgot the callee has to do it rather than caller.
The C0 code does not follow normal PPC calling convention. In fact, I think it uses blrl to call the C0 code.
EDIT:
I should also add that the non-volatiles are not pushed/popped by anything, and the volatile registers are not actually volatile...