Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Register usage
Message-ID: <25883@amdcad.AMD.COM>
Date: 7 Jun 89 02:04:33 GMT
References: <259@mindlink.UUCP> <25382@ames.arc.nasa.gov> <m0fRx4x-0001fDC@mipon2.intel.com> <25786@amdcad.AMD.COM> <m0fU2pe-0001hNC@mipon2.intel.com>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 27
Summary:
Expires:
Sender:
Followup-To:

In article <m0fU2pe-0001hNC@mipon2.intel.com> mcg@mipon2.UUCP (Steven McGeady) writes:
| In article <25786@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
| 
| [Steve talking about problems with multi-porting large register files]
| 
| >Well, we see no problems in either our 2nd or 3rd generation parts...
| 
| Well then, do speak up.  I can't imagine how you will effectively increase
| the number of ports in the register file without creating an imbalance
| between CPU speed and bus (because of poor register/cache balance).
| And I can't imagine how you will lower your CPI without it.  But then,
| perhaps I'm just not imaginative enough.

I think you are setting up a "straw-man" argument here.  We certainly
aren't talking about 2/3 of the die area as you previously implied.  The
Am29000's triple-ported, 192 register file currently takes about 21% of
the die area.  Even if we (hypothetically) doubled the number of ports
on it for a future generation part, standard process shrinks would still
end up making it a much smaller portion of the die than it already is.
It would end up being dwarfed by the large caches and multiple
functional units required to sustain multiple instruction/cycle
throughput.


	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)