Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!mips!zaphod.mps.ohio-state.edu!rpi!leah!bingvaxu!vu0310
From: vu0310@bingvaxu.cc.binghamton.edu (R. Kym Horsell)
Newsgroups: comp.arch
Subject: Re: Why FP at all? (was: Re: Killer Micro II)
Message-ID: <3961@bingvaxu.cc.binghamton.edu>
Date: 8 Sep 90 18:08:20 GMT
References: <STEPHEN.90Sep5000536@estragon.uchicago.edu> <14900015@hpdmd48.boi.hp.com>
Reply-To: vu0310@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (R. Kym Horsell)
Organization: SUNY Binghamton, NY
Lines: 23

In article <14900015@hpdmd48.boi.hp.com> sritacco@hpdmd48.boi.hp.com (Steve Ritacco) writes:
\\\
>Very true, who need IEEE format anyway.  Give me a processor capable of
                        ^^^^^^^^^^^^^^^^
>doing a few arithmetic instructions in a single cycle, with a single
>cycle multiply, and I think you've got it.  Lets use all the FPU silicon
\\\

Good G*d! The IEEE std _was_ intended to produce some kind of uniformity
in results across different kind of h/w. (A rather like the idea
of getting results accurate to the _bit_ in FP calcs).

Now, _some_ of us wouldnt go _near_ an FP calc in a month of weekends
but some of us like to waste cycles rather than $M simulating
the ``real'' world (where physics tells us we really dont _need_
FP since its all discrete; FP is just a handy hack) and sundry
other pursuits.

However, Im sure DSP guys _love_ this kind idea. The trouble comes
when they try to port their wizz-bang code to some other processor
(e.g. when their current chip/fabricator is superceded).

-Kym Horsell