Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: condition codes
Message-ID: <12426@mentor.cc.purdue.edu>
Date: 16 May 91 21:14:38 GMT
References: <12162@mentor.cc.purdue.edu> <13011@pt.cs.cmu.edu> <1991May15.003949.15076@watson.ibm.com>
Sender: news@mentor.cc.purdue.edu
Lines: 68

In article <1991May15.003949.15076@watson.ibm.com>, prener@watson.ibm.com (Dan Prener) writes:
> In article <12236@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
 
> |> Why do we have separate integer and floating units, especially without 
> |> communication between them?  I suggest those who push this horror look
> |> at how difficult conversion between them is.

			....................

                                                 If thereis a dichotomy, it
> |> is address/loop versus arithmetic, not integer versus floating.  There
> |> have been machines with this feature.  But even if one has this, it is
> |> still necessary to have good communication between the units.
> |> 
 
> We have separate integer and floating units because it helps make the
> machines fast.  It provides an easily-detected form of parallelism.
 
But if integers need to be used together with floating numbers, the 
conversion procedure loses more than what is gained by the parallelism.
Increased memory references are certainly not the way to get efficiency.

> Good communication between the units requires both the hardware real-
> estate for the data paths and, when such communication is used, the
> synchronization of the two units.  Good communication, like any other
> architectural feature isn't "necessary".  It is desirable, if the
> cost is low enough.  One must compute the expected performance return
> from adding such features.  As with any such computation of an expectation,
> this would include

The cost of the entire arithmetic unit on a computer is a relatively small
part of the cost of the computer.  I admit there might be a data path
problem, but why does it require synchronization?  Putting in a small
dedicated register memory, and using access to it to allow desynchronization,
should not be too difficult.  Even if the unit does conversion, the complexity
of the additional hardware should be quite simple.  Even if the conversion/
communication part is not too well optimized, it should still do much better
than the present.  

>    (1) how often such a feature would be used
>    (2) the performance improvement it would provide, when used
>  & (3) what performance degradation the machine would suffer from
>          having such a feature, even if it is not used (e.g., the
>          loss of other ways of spending the chip area)
> 
> Does anyone have any suggestions about what these numbers are?

As for (1), I suggest asking knowledgeable users for situations in which
they could take advantage of such features, or would be inconvenienced by
lack of them.  These users would have to understand architectural
considerations, and not just HLLs.  These considerations militate non-
obvious choices between algorithms, so testing specific algorithms is
not the answer.

I believe that the current elementary function library for the RS/6000
does quite a bit of this, and this might give an indication.

As for (2), it would reduce the cost of the hybrid operations down to
1/3 their present cost at least, and in some cases more.  For unsigned
integer to floating conversion, at present this takes an integer store,
a floating load, and a floating add, assuming that the preparations have
been made.  Other situations are even worse.

As for (3), possibly we should put in another chip.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)