Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Longer load/store because of register windows
Message-ID: <23403@amdcad.AMD.COM>
Date: 28 Oct 88 16:41:34 GMT
Article-I.D.: amdcad.23403
References: <156@gloom.UUCP> <310@lynx.zyx.SE> <332@pvab.UUCP> <15964@agate.BERKELEY.EDU> <23367@amdcad.AMD.COM> <16003@agate.BERKELEY.EDU>
Sender: news@amdcad.AMD.COM
Reply-To: tim@crackle.amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 24
Summary:
Expires:
Sender:
Followup-To:

In article <17268@shemp.CS.UCLA.EDU> marc@cs.ucla.edu (Marc Tremblay) writes:
| Having a multiple-window register file, or more precisely, having many
| registers, slows down the processor cycle. Even with an independent port for 
| the load/store, the operation is still based on the basic processor cycle.
| With a longer cycle the load/store accesses become slower. 

While larger register files do slow down register access by a very small
amount, I don't think that the register file access is really the
critical path on most machines (it certainly isn't the main critical
path on the Am29000).  As has been stated here before, cache accesses
(for instructions, data, or both), or MMU translations are probably the
limiting factor.

The emperical evidence also tends to support this:  both Am29000 and
SPARC (with large register files) have 30MHz versions available, while
MIPS and 88000 (32-register files) are at 20 - 20MHz.  Note that this
certainly does not mean that they couldn't be at 30MHz, I'm just
pointing out that the register file size has little to do with the
overall cycle time in real processors.


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