Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!jarthur!usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: 386 Clones [really: IEEE floating point & various approaches; long]
Message-ID: <4186@goanna.cs.rmit.oz.au>
Date: 2 Nov 90 07:51:54 GMT
References: <1990Oct26.015244.586@amd.com> <8464@scolex.sco.COM> <42618@mips.mips.COM>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 74

In article <42618@mips.mips.COM>, mash@mips.COM (John Mashey) writes:
> 	1b
> 	"There are five types of exceptions that shall be signaled when
		   ****
> 	detected.  The signal entails setting a status flag, taking a
> 	trap, or possibly doing both. With each exception should be
> 	associated a trap under user control, as specified in Section 8.
> 	THE DEFAULT RESPONSE TO AN EXCEPTION SHALL BE TO PROCEED WITHOUT
> 	A TRAP....For each type of exception the implementation shall
> 	provide a status flag that shall be set on any occurrence of
> 	the corresponding exception when no corresponding trap occurs."
> 
> 	1c
> 	"A user should be able to request a trap on any of the five
> 	exceptions by specifying a handler for it......When an
					       **
> 	exception whose trap is disabled is signaled, it shall be
> 	handled in the manner specified in Section 7. [mash: i.e.,
> 	by setting setting flags]  WHEN AN EXCEPTION WHOSE TRAP IS ENABLED
> 	IS SIGNALED THE EXECUTION OF THE PROGRAM IN WHICH THE EXCEPTION
> 	OCCURRED SHALL BE SUSPENDED, THE TRAP HANDLER PREVIOUSLY SPECIFIED
> 	BY THE USER SHALL BE ACTIVATED, AND A RESULT, IF SPECIFIED IN
> 	SECTION 7, SHALL BE DELIVERED TO IT."  goes on to describe what
> 	trap handlers can do.

> 	b) On most, if not all IEEE-compliant machines, if you put
> 	a trap in for SIGFPE, you get feature 1c;

It's worth pointing out that SIGFPE does not meet the IEEE criteria.
SIGFPE is a blanket "some kind of floating point exception, or maybe
some kind of integer exception, _I_ know but I'm not going to tell _you_".
(That is, according to SVID 2.  I don't know what SVr4 does.  4.xBSD
does have the courtesy to tell you what kind of exception you got.)
The IEEE standard calls for *separate* enabling and disabling of each
of the five traps, with separate handlers of the user's choice for each.
I'm going to cite the SVID rather than 1003.1, and that's for two reasons.
First, my copy of 1003.1 is in another city and I don't remember exactly
what it says.  Second, the degree to which the RS/6000 behaviour has
something to do with the degree to which you have been able to rely on
SIGFPE in the past, and 1003.1 is not the past.  The SVID says that
	SIGFPE		floating-point exception
			[What does this mean?  Which things generate
			exceptions?  The SVID does not say.  You have
			never been given _any_ guarantee.]
when you supply a handler:
	"the receiving process is to execute the signal-catching function...
	The signal number sig [here SIGFPE] will be passed as the only
	argument to the signal-catching function.
	Additional arguments may be passed to the signal-catching
	function for hardware-generated signals."
	[The last two sentences seem contradictory.  I take it that if
	you have hardware floating point it may pass additional arguments
	to your signal handler, but a software emulation may only pass
	SIGFPE and nothing else.  Absurd, but that seems to be what it says.]
	"Upon return from the signal-catching funciton, the receiving
	process will resume execution at the point at which it was
	interrupted, except for implementation defined signals where this
	may not be true."
	[I.e. it's anyone's guess what return from a handler may do, but
	the system documentation should _say_.]
			
So UNIX code written to the SVID
    -- never had any guarantee about what floating-point operations
       could generate signals
    -- had no way of telling the difference between underflow and overflow
       or for that matter between overflow and INTEGER divide by 0
    -- had no way of finding out where the exception had occurred
    -- could not resume or bypass the operation, but had either to
       halt the program or longjmp() out

UNIX systems providing IEEE-conforming traps do exist, but differ.
-- 
The problem about real life is that moving one's knight to QB3
may always be replied to with a lob across the net.  --Alasdair Macintyre.