Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: 386 Clones [really: IEEE floating point & various approaches; long]
Message-ID: <42618@mips.mips.COM>
Date: 1 Nov 90 20:29:55 GMT
References: <1990Oct26.015244.586@amd.com> <8464@scolex.sco.COM> <42597@mips.mips.COM> <4174@goanna.cs.rmit.oz.au>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 84

In article <4174@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <42597@mips.mips.COM>, mash@mips.COM (John Mashey) writes:
>> Note, also, that this somewhat applies to the IBM RS/6000 series.
>> Legally, but unlike almost all other IEEE FP implementations,
>> FP OPERATIONS DO NOT NORMALLY TRAP ON EXCEPTION CONDITIONS;
>> i.e., SIGFPE doesn't normally do anything.
>
>Am I missing something?  Any floating-point system where the *default*
>mode of operation is to generate traps does *NOT* in that mode conform
>to the IEEE 754 standard.  If you _want_ traps, then you have to call
>some system-specific extension to get them.  So the complaint appears
>to be that the RS/6000 (like the Sun implementations of floating point)
>conforms to the letter of the standard.

Sorry,  I guess I wasn't clear enough. Let me say what I said again,
but explain further:

1) In IEEE 754:
	1a
	"The implementor may, at his option, implement the following
	modes: traps disabled/enabled, to handle exceptions."

	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.

2) Now, I take from this that what IBM did IS legal, from 1a above:
they basically made trapping exceptions impossible in normal code
(unless you run in "sequentialize" mode, which is NOT something you'd
do except for debugging.) 

3) Now, what I meant in the original quote is:
	a) The default (for anybody) is to ignore exceptions,
	if nobody says anything.
	b) On most, if not all IEEE-compliant machines, if you put
	a trap in for SIGFPE, you get feature 1c; at least, you get
	an exception signalled, and at worst, you go to a part of the
	run-time that tells you something went wrong, and where, and how.
	At best, you get a trap handler than can do what 1c says,
	fixing up values, etc. (I don't know how well all the various
	implementations are at doing this.)
	You get this on the same binary that you would normally distribute,
	that runs at full speed, and you get it by including 1 statement.
	You DO NOT GET this effect from the same IBM binary that
	runs at full speed. 

4) So, anyway, the point is: it's perfectly legal, (and the committee
carefully allowed for such things), but the effect is different:
if you just compile the same portable code that may run on many other
machines, and on those machines, will at least report exceptions
fairly precisely, in the binary you'd distribute, you will NOT get
that effect on the IBMs.  Clearly, the supercomputer world has proved
that there exists a market that wants max speed, perhaps with some
loss in error handling. People should understand what the difference
is.

Now, how about input from people who actually develop FP programs:
a) Do you use traps for SIGFPE, or not?
b) If SIGFPE doesn't do anything, and you have to change the source code
widely to check for traps, is this: no problem, slightly painful,
or excruciating.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086