Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Re: Universal OS (was Re: Survey of architectures)
Message-ID: <7776@brl-smoke.ARPA>
Date: 27 Apr 88 15:49:48 GMT
References: <50825@sun.uucp> <670016@hpclscu.HP.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <670016@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>For instance, SIGFPE (which now has an underground subcode which may mean
>just about anything, depending on what system you are on..) could either have
>an ARCHITECTED subcode, or be changed to a whole new array of codes, for
>different things like Integer Overflow, Divide by zero, Floating-point
>underflow and so on... 

No matter how much work you put into an attempt to specify a fully
general (i.e. portable) floating-point exception status data structure,
I guarantee I can dream up a floating-point architecture that you
haven't accommodated.  There is nothing that forbids implementation-
dependent extensions for SIGFPE handlers, but you need to be aware
that they ARE implementation dependent.

Frankly, I think you should consider SIGFPE a fatal symptom that
indicates that you haven't designed a good enough algorithm; the
correct solution is to fix the algorithm, not interpret the state
of the floating-point processor once it's already too late.  The
simple use of SIGFPE is sufficient for this.