Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!ames!amdcad!proton!davec
From: davec@proton.amd.com (Dave Christie)
Newsgroups: comp.arch
Subject: Re: Pipelined FP add (Separate Register Sets)
Message-ID: <28413@amdcad.AMD.COM>
Date: 15 Dec 89 15:10:18 GMT
References: <241@dg.dg.com> <33570@hal.mips.COM> <3740@brazos.Rice.edu> <38132@ames.arc.nasa.gov>
Sender: news@amdcad.AMD.COM
Reply-To: davec@cayman.amd.com (Dave Christie)
Distribution: na
Organization: Advanced Micro Devices, Inc., Austin, Texas
Lines: 45
Summary:
Expires:
Sender:
Followup-To:

In article <38132@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
| In article <3740@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
|   
    [discussion about separate vs. multi-port shared fp/int registers
     and integer/fp register allocation tradeoffs]
| 
| >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.

This technique is fairly common in machines from the '70s (at least CDC machines)
that used small off-the-shelf single-port SRAMS for the register file. Doubling
the register file realestate is well worth it for the improved performance that
comes with accessing two operands at once.  (Small off-the-shelf multi-ported
SRAMS didn't quite cut it for various reasons.)

The extra ports that come free with separate register sets aren't the only benefit:
Preston alluded to the removal from the compiler of a difficult optimization
tradeoff (int vs. fp register allocation).  (But I think one could argue about 
whether or not this an enhancement, i.e. not having the opportunity to do it.)

Another benefit appears for multiple instruction issue: issuing simultaneous
fp/int instructions is simplified if you don't have to worry about dependency
checking between the two (witness IBM 360/91, i860, Apollo Prism(?separate register
sets?).  It also makes it easier to put all fp operations on a separate chip and
still maintain high performance (a la MIPS).

| 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.
   [in a shared register set]

Quite true, but (IMHO) for most applications, int<->fp traffic is not very
high, so having to explicitly move some data around is no big deal ... as
long as it is done reasonably efficiently so that you don't blow one or two
applications out of the water.

------------
Dave Christie         My humble opinions, not my employer's.