The following details certain aspects of the Alpha architecture that have significant implications for exception handling. The rules presented are designed to ensure correct operation across all implementations of that architecture. As with all aspects of this calling standard, optimization information may ensure correct behavior as if these rules were followed without appearing to explicitly do so.
Alternative approaches that exploit implementation-specific characteristics are also possible, but are outside the scope of this standard.
The Alpha hardware architecture allows instructions to complete in a different order than that in which they were issued, and for exceptions caused by an instruction to be raised after subsequently issued instructions have been completed. Because of this, the state of the machine when a hardware exception occurs cannot be assumed with precision unless it has been guaranteed by bounding the exception range with the appropriate insertion of TRAPB instructions.
The rules for bounding the exception range are as follows:
These rules ensure that exceptions are detected in the context within which exception handlers have been set up to handle them.
These rules do not ensure that all exceptions are detected while the procedure within which the exception-causing instruction was issued is current. For example, if a procedure without an exception handler is called by a procedure that has an exception handler that is not sensitive to invocation depth, an exception detected while that called procedure is current may have been caused by an instruction issued while the caller was the current procedure. This means that the frame, designated by the exception-handling information, is the frame that was current when the exception was detected, not necessarily the frame that was current when the exception-causing instruction was issued.
The Alpha architecture guarantees neither that instructions are completed in the same order in which they were fetched from memory nor that instruction execution is strictly sequential. Continuation after some exceptions is possible, but there are restrictions, as reflected in the following discussions.
Software-raised general exceptions are, by definition, synchronous with the instruction stream and can have a well-defined continuation point. Thus, a handler may have the option of requesting continuation from a software-raised exception. However, since compiler-generated code typically relies on error free execution of previously executed code, continuing from a software-raised exception may produce unpredictable results and unreliable behavior unless the handler has explicitly fixed the cause of the exception in such a way as to be transparent to subsequent code.
Hardware faults on Alpha systems follow rules that, loosely paraphrased, state that if the offending exception is fixed, re-execution of the instruction (as determined from the supplied PC) will yield correct results. This does not imply that no instructions following the faulting instruction have been executed (see the Alpha System Reference Manual for more details). Hardware faults can therefore be viewed as similar to software-raised exceptions and can have well-defined continuation points.
Arithmetic traps cannot be restarted since all the information required for a restart is not available. The most straightforward and reliable way in which software may guarantee the ability to continue from this type of exception is by placing appropriate TRAPB instructions in the code stream. Although this does allow continuation, this technique must be used with extreme caution due to the negative side effect on application performance. A more sophisticated technique that requires typically one TRAPB per basic block is described in the Alpha System Reference Manual, Section 4.7.5.1, Imprecise/Software Completion Trap Modes.