🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22411

Re: 64 bit registers

#22411
From: John Mashey
Date: Mon, 12 Feb 1990 20:42
49 lines
2989 bytes
In article <11121@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes:
>In article <1990Feb12.133414.1661@oracle.com> csimmons@oracle.com writes:
>>Now that FPUs and ALUs are being implemented on the same chip, maybe
>>it would make sense to implement a single register set instead of
>>two separate register sets.  It would probably simplify certain aspects
>>of register allocation in compilers.  Of course, the 88K seems to have
>>kept two separate register sets...
>>
>>-- Chuck
>
>
>The 88100 only has one set of registers (using pairs for double precision
>floating point).  Rumor has it that the 88110 will have a separate set of
>80-bit FP registers (as well as lots of other goodies).


As has been discussed earlier, although having a single set of registers
may simplify some things (it does), it also makes other things more
complex:
	a) FP registers are naturally 64-bit things.
	b) Typically, current RISCs have 2 read + 1 write port 32-bit integer
	register files.  (there are variations of course, but thisworks well
	with most of the current 3-operand integer pipelines).
	c) FP register files often want more ports, especially given that
	the inherently multi-cycle operations need to do writes, and
	you get stalls if there aren't enough ports.
	The more parallel units you have, the more ports you're likely to
	need, or else, you go to relabeling schemes, or else you get
	more stalls.
Hence, there is a reason that most machines have separate integer and FP 
registers: it's an easy way to get more cheap register ports, leave the
integer datapath 32-bits wide, and have the FP one 64-bits wide.

	d) Now, think about what happens if you go with one of the superscalar
	pipelines: you've just upped the number of register references that
	need to be satisifed by at least 2 (for 2-way superscalar), or
	more (for more).  Of course, appropriate statistical analysis may
 	help you make the right tradeoffs, because this could start to get
	expensive, and if you do something fancy in one part of the pipeline,
	and don't improve the access to machine resources in a well-balanced
	fashion, you're not going to gain as much as you thought.

Anyway, if they really are putting a separate set of registers, it will
certainly be a good thing for them.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID: <35853@mips.mips.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!pyramid!prls!mips!winchester!mash
References: <11121@encore.Encore.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!pyramid!prls!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: 64 bit registers
Message-ID: <35853@mips.mips.COM>
Date: 12 Feb 90 20:42:06 GMT
References: <11121@encore.Encore.COM>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 49