Path: utzoo!utgpu!water!watmath!clyde!rutgers!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.arch
Subject: Re: Performance increase - a suggestion
Message-ID: <3127@phri.UUCP>
Date: 30 Jan 88 03:09:59 GMT
References: <235@unicom.UUCP> <28200089@ccvaxa>
Reply-To: roy@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 27

In article <28200089@ccvaxa> aglew@ccvaxa.UUCP writes:
> I wonder how much interest might be out there for a true double-precision
> floating point engine - one that did 64 bit floating point, or IEEE 80
> bit extended floating point, or even 128 bit floating point, as its
> native floating point mode, as fast as single precision on nearly any
> other machine in its price range?

	I don't know about price range, but doesn't the FPS-164 do
exclusively 64-bit floating point?

	Actually, I wonder if a RISC-FPP would make sense.  Consider a
machine like a Vax.  Let's say we got rid of all the multiple precision
floating point formats and instructions (at last count, F, D, G, and H; did
I miss any?) and made all floating point math a single high-precision
format.  Clearly that would save silicon.  If we took that silicon real
estate and devoted it to making that single floating point format work
faster, could we build a machine which only has double precision, but does
it as fast as the old vax did single precision?

	Given that we could do double floating math as fast as single
floating math, the only advantage single would have left would be saving
memory on large arrays.  Maybe we'd have to keep {load,store}
{single,double} instructions around for that.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016