• PPC Exception: Exception which are specific to the PPC architecture.
• Interrupt: A certain type of a PPC exception, caused by asynchronous events by external hardware.
• Java Exception: Exception defined in the Java language specification. All Java exceptions are extensions of the class Throwable.

Types of Java-Exceptions

Each PPC exception is caused by a synchronous or asynchronous event and causes the processor to switch to supervisor mode and jump to the proper exception vector.

PPC Exceptions and Interrupts

Exception classes and their corresponding exception methods have to be specified in the configuration. Instances of these classes are never created and therefore the object constructors are defined as synthetic and will not be translated into code.
The code generator has to create a special exception stack frame and must conclude the method with the instruction rfi.
The reset exception must not have a prolog, as there is no stack yet. This poses a special problem if the space in the exception table is not sufficient to hold the code of the reset exception. In such a case simply calling a method is not allowed but must be handled by setting up a temporary stack pointer first.

Mit US.ENABLE_FLOATS werden alle volatile FPR's gespeichert und das FP-Enable Bit im MSR gesetzt. Die nonvolatile FPR, die in einer Methode benutzt werden, werden bereits durch den Methodenprolog gesichert. US.ENABLE_FLOATS kann in einer Exception-Methode oder in einer Methode, die durch eine Exception-Methode aufgerufen wird, plaziert werden.
Auch wenn wie im Falle des Decrementers eine action-Methode aufgerufen wird und diese in einer Unterklasse überschrieben wird, muss die action-Methode der Unterklasse US.ENABLE_FLOATS aufrufen, weil in der Decrementer-Exception Methode ja noch nicht klar ist, dass die Floats benützt werden. Werden aus dieser action-Methode weitere Methoden (z.B. Math.sin) aufgerufen, muss dort drin US.FLOAT_ENABLE() nicht mehr aufgerufen werden.

Each Java exception causes a PPC program exception. The handler receives the thrown exception like a parameter in the first parameter register R2. The code generator has to make sure that this parameter is copied into R2 during the prolog of the program exception handler. The handler does the following:

• Get address of causing instruction into variable addr from SRR0.
• Read instruction at this address
• Determine from type of instruction which kind of exception was thrown
• If unchecked instruction: create exception such as ClassCastException, ArrayIndexOutOfBoundsException, etc.
• copy parameter exception into register R2
• copy parameter addr into register R3
• branch to compiler specific subroutine handleException.

The following steps have to be taken:

• Search end of method from addr (end at pattern 0x000000yy)
• Search exception in exception table at end of method → start < addr < end && exception instanceof type.
• If exception is found → put handler address into SRR0, rfi.
• If not found →
  1. get address of call to this method (LR) from stack frame, copy into variable addr (in R3).
  2. replace LR in the stack frame with address of handleException subroutine.
  3. get address of epilog from exception table and branch to this address, this causes the unwinding of this method.

When the unwinding of a method is done, the flow of control automatically returns to handleException, because we modified the stack frame accordingly.

The figure below gives an example for the handling of exceptions.

Example for handling of exceptions