The purpose of this webpage is to accumulate and disseminate information about the exception handling in currently available "comodity" chips. For my purpose, a comodity chip is one that is produced in sufficient quantity that more than one "secret" application is known.

A bit of background. As is probably known to you, William Kahan of Berkeley has led the fight for a floating point standard. This is IEEE Standard 754 (binary) and IEEE Standard 854 (decimal). A good general introduction is Goldberg's "What Every Computer Scientists Should Know About Floating Point". This is available on Sun's documentation website: doc.sun.com. It is also available in Computing Surveys, 1991. The Standard describes many things, including a standard set of exceptions that must be available.

Not so amazingly, chip manufacturers have not rushed right out to implement the standard. For example, the x86 chips have a "denormalization" exception and an "inexact"; the semantics of denormalization are not immediately obvious.

Something that is amazing, however, is the cavalier attitudes
toward *integer* exceptions. This has been tossed around
in the "arithmetic" community but is not so widely understood by
the general programmer. The following quote is from Sun's
documentation site:

.... Integer division by zero (FPE_INTDIV) and integer overflow (FPE_INTOVF) are also included among the SIGFPE types, but because they are not IEEE floating point exceptions you cannot install handlers for them via ieee_handler. (You can install handlers for these SIGFPE types via sigfpe(3); note, though, that integer division by zero is either ignored or generates SIGILL on PowerPC systems, and integer overflow is ignored on all SPARC, Intel, and PowerPC systems. On SPARC and Intel systems, special instructions can cause the delivery of a SIGFPE signal of type FPE_INTOVF, but Sun compilers do not generate these instructions.)

Invalid Instruction

Overflow

Underflow

Divide by Zero

Inexact Result

Overflow

Divide by Zero

In the table below, "floating-point compliance" means having exactly the five listed exceptions and "integer compliance" means having exactly the two listed. Chips can comply or not comply in lots of ways. I'll worry about how they do/do not comply after I see what the possible ideas are.

Manufacturer | Designation | Compliant? | Remarks |
---|---|---|---|

Sun | Ultra | Yes | |

Intel | x86 | No | Extras |

Motorola | PowerPC | Yes | fpscr register |

DEC | Alpha | Very messy | |

QED | MIPS R4600 | Yes | Sold By IDT, NKK, Toishiba |

QED | MIPS R4700 | Yes | |

QED | MIPS R4640 | Yes | Sold By IDT, NKK, Toishiba |

QED | MIPS R4650 | Yes | Sold By IDT, NKK, Toishiba |

QED | MIPS R5000 | Yes | Sold By IDT, NKK, Toishiba |

QED | MIPS RM52xx | Yes | |

QED | MIPS RM7000 | Yes |

Manufacturer | Designation | Compliant? | Remarks |
---|---|---|---|

Sun | Ultra | Conditionally | |

Intel | x86 | Conditionally | |

Motorola | PowerPC | Overflow | No 0 divide |

ARM C | No | Flag state only | |

QED | MIPS R4600 | No divby2 | Sold By IDT, NKK, Toishiba |

QED | MIPS R4700 | No divby2 | |

QED | MIPS R4640 | No divby2 | Sold By IDT, NKK, Toishiba |

QED | MIPS R4650 | No divby2 | Sold By IDT, NKK, Toishiba |

QED | MIPS R5000 | No divby2 | Sold By IDT, NKK, Toishiba |

QED | MIPS RM52xx | No divby2 | |

QED | MIPS RM7000 | No divby2 |

Last modified: Wed Aug 5 10:50:15 EDT 1998