The Alpha Back End

Trap Shadows, Floating Exceptions, and Denormalized Numbers on the DEC Alpha

See section 4.7.5.1 of the Alpha Architecture Reference Manual.

The Alpha has imprecise exceptions, meaning that if a floating point instruction raises an IEEE exception, the exception may not interrupt the processor until several successive instructions have completed. ML, on the other hand, may want a "precise" model of floating point exceptions.

Furthermore, the Alpha hardware does not support denormalized numbers (for ``gradual underflow''). Instead, underflow always rounds to zero. However, each floating operation (add, mult, etc.) has a trapping variant that will raise an exception (imprecisely, of course) on underflow; in that case, the instruction will produce a zero result AND an exception will occur. In fact, there are several variants of each instruction; three variants of MULT are:

MULT s1,s2,d

truncate denormalized result to zero; no exception

MULT/U s1,s2,d

truncate denormalized result to zero; raise UNDERFLOW

MULT/SU s1,s2,d

software completion, producing denormalized result

The hardware treats the MULT/U and MULT/SU instructions identically, truncating a denormalized result to zero and raising the UNDERFLOW exception. But the operating system, on an UNDERFLOW exception, examines the faulting instruction to see if it's an /SU form, and if so, recalculates s1*s2, puts the right answer in d, and continues, all without invoking the user's signal handler.

Because most machines compute with denormalized numbers in hardware, to maximize portability of SML programs, we use the MULT/SU form. (and ADD/SU, SUB/SU, etc.) But to use this form successfully, certain rules have to be followed. Basically, d cannot be the same register as s1 or s2, because the opsys needs to be able to recalculate the operation using the original contents of s1 and s2, and the MULT/SU instruction will overwrite d even if it traps.

More generally, we may want to have a sequence of floating-point instructions. The rules for such a sequence are:

1. The sequence should end with a TRAPB (trap barrier) instruction. (This could be relaxed somewhat, but certainly a TRAPB would be a good idea sometime before the next branch instruction or update of an ML reference variable, or any other ML side effect.) 2. No instruction in the sequence should destroy any operand of itself or of any previous instruction in the sequence. 3. No two instructions in the sequence should write the same destination register.

We can achieve these conditions by the following trick in the Alpha code generator. Each instruction in the sequence will write to a different temporary; this is guaranteed by the translation from ML-RISC. At the beginning of the sequence, we will put a special pseudo-instruction (we call it DEFFREG) that ``defines'' the destination register of the arithmetic instruction. If there are $$K arithmetic instructions in the sequence, then we'll insert $$K DEFFREG instructions all at the beginning of the sequence. Then, each arithop will not only ``define'' its destination temporary but will ``use'' it as well. When all these instructions are fed to the liveness analyzer, the resulting interference graph will then have inteference edges satisfying conditions 2 and 3 above.

Of course, DEFFREG doesn't actually generate any code. In our model of the Alpha, every instruction generates exactly 4 bytes of code except the ``span-dependent'' ones. Therefore, we'll specify DEFFREG as a span-dependent instruction whose minimum and maximum sizes are zero.

At the moment, we do not group arithmetic operations into sequences; that is, each arithop will be preceded by a single DEFFREG and followed by a TRAPB. To avoid the cost of all those TRAPB's, we should improve this when we have time. Warning: Don't put more than 31 instructions in the sequence, because they're all required to write to different destination registers!

What about multiple traps? For example, suppose a sequence of instructions produces an Overflow and a Divide-by-Zero exception? ML would like to know only about the earliest trap, but the hardware will report BOTH traps to the operating system. However, as long as the rules above are followed (and the software-completion versions of the arithmetic instructions are used), the operating system will have enough information to know which instruction produced the trap. It is very probable that the operating system will report ONLY the earlier trap to the user process, but I'm not sure.

For a hint about what the operating system is doing in its own trap-handler (with software completion), see section 6.3.2 of ``OpenVMS Alpha Software'' (Part II of the Alpha Architecture Manual). This stuff should apply to Unix (OSF1) as well as VMS.

Lal George Allen Leung
Generated by mltex2html
Last modified: Mon Jun 8 14:18:05 UTC 2009 by buildd@vernadsky