Question

I’m writing an assembler routine to handle the 0x500 external/decrementer exception in an EABI embedded PowerPC application.

In my assembler routine called from the 0x500 vector point I want to use some memory to context save registers before branching to the handler function in ‘C’.

Because
i) the exception model guarantees the previous instructions will have finished by the time the exception handler runs
AND
ii) the calling convention appears to update the stack pointer (r1) first on entering a new function, before using the new stack space freed up by moving it (and move the stack pointer back to where it was last at the end of the function)

it appears to me that I can safely use r1 to give myself some more space on the normal stack in the exception processing routines, provided obviously I adhere to the calling convention and put the stack back how I found it and make sure SRR0 and SRR1 are unmodified.

I’m not going to allow exceptions that use the stack in their handling to nest (although actually using this method I’m not sure there would be a problem).

Do you think this is a wise approach, or should I use a separate stack for exception handling? – I’m thinking this may bring with it its own problems.

Answer 1

Embedded systems do this both ways. If you are completely confident that the stack pointer will always point to a valid frame and there will room in the stack for your new frame, then go ahead and use it. If there’s a chance that the stack pointer will not always be valid, you should save the old stack pointer (typically in an SPRG) and set up your own.

If you’re going to handle data access exceptions to detect software errors, you’ll certainly want to set up your own exception stack because the DACC may have been caused by a broken stack pointer.