Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Pipelined FP add
Message-ID: <38132@ames.arc.nasa.gov>
Date: 14 Dec 89 22:00:46 GMT
References: <241@dg.dg.com> <33570@hal.mips.COM> <3740@brazos.Rice.edu>
Sender: usenet@ames.arc.nasa.gov
Distribution: na
Organization: NASA - Ames Research Center
Lines: 30

In article <3740@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
>In article <33570@hal.mips.COM> mark@mips.COM (Mark G. Johnson) writes:

>>that the 88K's shared register file -- same regs for integer and FP
>>operands -- required large numbers of read and write ports to make

>The point about read/write ports is good.  I used to believe
>in a single (large) set of multi-purpose registers controlled
>by the compiler.  This scheme would seem to be less wasteful

>In particular, I prefer seperate FP and integer register sets.

There are alternatives.  For example, instead of creating
separate register files to increase the available ports, there is a
technique to use two identical register files for the same purpose.
The technique was used on the Cyber 205, and is described in an article
in IEEE Transactions on Computers [May 1982] by Neil Lincoln.  This redundancy
doubles the real estate per register, but, on the other hand, there
are advantages to doing this over using separate fp register files.
Codes which require movement of data between
integer registers, where the logical and bit-crunching instructions work,
typically, and the fp register file, don't require data movement.
(I hope nobody still uses the IBM 360 setup, where you have to push
the data to *memory* to get it back and forth between integer and fp units...)


  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117