Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!sun.soe.clarkson.edu!rpi!itsgw!steinmetz!crdgw1!uunet!mcvax!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <8051@boring.cwi.nl>
Date: 24 Apr 89 22:47:18 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <17417@cup.portal.com> <38971@bbn.COM> <100524@sun.Eng.Sun.COM> <39049@bbn.COM>
Organization: CWI, Amsterdam
Lines: 31

In article <39049@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
 > Lots of valid uses of IEEE features listed.  I didn't mean that IEEE
 > was bad or useless, it's just that it was architected when CISC was
 > the trend, and it shows.  Especially after my own efforts in an IEEE
 > implementation, I am glad to see from this posting and others that at
 > least a few users can make use of the features.  I think the RISC
 > implementers should have a RISC-style floating point standard, though.

Oh, go ahead, but make sure you have some numerical analysts around to
help you, unless you are willing to make the same mistakes as numerous
designers before you have made.

To some of your points:

Round to even gives a better overall round-off error than truncate to
zero (i.e. better in larger expressions).

Gradual underflow is, as far as I see, not really needed, but the
alternative is trap on underflow, and allow the program to recover.
This would be just as hard, if not harder, in my opinion.

David Hough remarked that many applications are written to work
properly on a lot of machines and that they would not benefit very
much from IEEE arithmetic.  I might say that for a number of those
applications this was achieved with much trouble.  The original
design would, in a lot of cases, have benefitted if *only* IEEE
arithmetic had to be considered.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax