Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpcc01!hpdmd48!sritacco
From: sritacco@hpdmd48.boi.hp.com (Steve Ritacco)
Newsgroups: comp.arch
Subject: Re: Why FP at all? (was: Re: Killer Micro II)
Message-ID: <14900015@hpdmd48.boi.hp.com>
Date: 7 Sep 90 23:34:38 GMT
References: <STEPHEN.90Sep5000536@estragon.uchicago.edu>
Organization: Hewlett Packard - Boise, ID
Lines: 30

> putting integrated floating point into a silly little workstation like
> a Sparc or an 80486 machine is serious overkill (and I'm almost
> serious: these machines aren't fast enough for editing anymore) and a
> poor use of gates. Especially since, I conjecture, emulation could
> theoretically be faster.

This I agree with.  Especially when we are talking about the possibility
of single processors executing multiple instructions per cycle.  

> Is it so absurd to suggest that there might be PARTS of floating point
> instructions that, in the hands of a good optimiser, might be used to
> generate better code than their wholes (remembering the VAX CALLS
> linkage... :-)?
>
> Is it so absurd to suggest, in sum, that exposing separate mantissa
> and exponent to the optimiser might result in *speedup* due to
> constant propagation and expression-rearrangement, while at the same
> time increasing expressivity by allowing an INDEPENDENT choice of
> mantissa and exponent sizes?

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
to do more needed operations and good floating point could fall out anyway.

> Is it so absurd to suggest that the effort and the silicon that go
> into an FPU might be better spent on supporting some other datatype
> that is of more _general_ applicability?

Might be worth a try.