Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: Denorms, Infs, and NaNs (was: Alignment on RS/6000)
Message-ID: <46978@apple.Apple.COM>
Date: 30 Nov 90 18:55:27 GMT
References: <13342@encore.Encore.COM> <46866@apple.Apple.COM> <1990Nov29.191342.669@panews>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 27

[]
> jsalter@slo.awdpa.ibm.com (Jim Salter) writes: (replying to me)
>
>Many of the conversion routines (str -> fp, fp -> str) also must handle
>Denorms, Infs and NaNs.  The routines would run much faster if they didn't
>have to check for all these special cases.

Well, either denorms, etc. happen often, in which case hardware is justified,
or they are really rare, in which case RISC(tm) philosophy is let the
software do it.

I'm not on a soapbox saying IEEE conventions are stupid, or that we shouldn't
handle them in hardware, I'm trying to determine what the trade-off: how
often it happens, and what's the cost either way.
>
>No.  Routines can either produce intermediate *or* end-results which are
>denorms, whether the input is denormal or not (see Sec. 7.4 IEEE 754).

I have no doubt that is the case. The question is how often, how hard it
would be to handle it completely in software, what support could be put
into trap handlers, etc. to make recovery acceptably fast, what is the
minimum amount of hardware to put in the FP box so that normal cases don't
down, and so that trap handlers can fix then up and return quickly

--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum