Path: utzoo!utgpu!water!watmath!clyde!motown!vilya!lcuxlm!whuts!att!rutgers!gatech!bloom-beacon!husc6!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: separate integer and float register
Message-ID: <507@m3.mfci.UUCP>
Date: 18 Aug 88 12:44:55 GMT
References: <2724@wright.mips.COM> <6800002@modcomp> <1241@garth.UUCP>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 38

In article <879@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>In article <1241@garth.UUCP>, walter@garth.UUCP (Walter Bays) writes:
>> In article <6800002@modcomp> joe@modcomp.UUCP writes:
>> >Special floating point registers also slow down context switching, due
>> >to the extra time needed to save/restore them.
>> 
>> More registers slow down context switching, whether integer or floating
>> point, windowed or conventional.
>Unless there is a big time improvement in having separate register sets,
>one gains from the ability to trade off between registers used for integers
>and floating point registers.  I doubt that enough can be gained by having
>separate register sets to compensate for the losses.

For conventional machines you have a point.  For a machine with
multiple independent functional units (a VLIW, for instance) I don't
think it's even debatable.  Ideally, the compiler would most like a
huge register file, shared by all functional units.  In our case,
that would be something like 28 functional units sharing a register
file that was 32 bits wide and something like 1K deep.  That's 28
read ports, assuming you don't want more to help with stores.  And
unless you're willing to put crossbars or shared ports you'd need
about that many write ports.  Even slicing the register file by 1
bit at a time you'd never fit the pins needed (28*10 just for reg
read selection).  Never mind how the heck you'd get all those
functional units anywhere near the register file to try to get some
usable cycle time.

For some machine architectures, you have to split up the registers
into sets, and once you've done that, I think an I/F split makes
better sense than some IF/IF partitioning.  In our machine, the F
side can do integer ops anyway.



Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090