jsalter@slo.awdpa.ibm.com (11/30/90)
In article <46866@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >[] >>In article <13342@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: Re: returning NaNs, Infs and Denorms is probably because of a bug and should just core dump... >>This is probably true for NaN's and Infinities, but Denorms occur all the >>time. printf() often generates them when dealing with floats, and the >>math library routines do also. It isn't true for NaNs and Infs, either. NaNs and Infs return valuable information if you know what to look for (i.e. you know IEEE [78]54; Sec. 3.1.4.2 - 80387 Programmer's Ref. Manual [1987] - Intel). >I still don't understand the assertion that Denorms occur all the time. >Just because printf() knows how to handle them doesn't mean that it >happens very often. Likewise the math routines. What is your evidence >than it happens "often" (whatever that means- 1% is incredibly often by >my definition in this case) 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. >If you are saying that printf() and the math libraries can produce intermediate >results internally which are denorm, even if the inputs and outputs aren't, >would it be possible to re-write them to avoid it (given the impetus that >perhaps denorms are really slow)? 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). The i387 attempts to normalize most values, but sometimes can't. And sometimes it doesn't understand denorms correctly, either, but that's another matter... It would make life much easier on math libraries and conversion routines if we didn't have to account for them, but we do. > baum@apple.com (408)974-3385 >{decwrl,hplabs}!amdahl!apple!baum jim/jsalter IBM AWD, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter PS/2 it, or DIE! :-) The ramblings above have nothing to do with Big Blue.
baum@Apple.COM (Allen J. Baum) (12/01/90)
[] > 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