Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Longer load/store because of register windows Message-ID: <7195@winchester.mips.COM> Date: 27 Oct 88 23:32:29 GMT References: <156@gloom.UUCP> <310@lynx.zyx.SE> <332@pvab.UUCP> <15964@agate.BERKELEY.EDU> <23367@amdcad.AMD.COM> <16003@agate.BERKELEY.EDU> <469@oracle.UUCP> <7041@winchester.mips.COM> <17268@shemp.CS.UCLA.EDU> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 26 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. >There are two reasons: 1) for a large register file, let's say 128 registers, >the decoding of the registers addresses is longer (more bits to decode, >even if you use partial decoding there is still a penalty), >2) the data bus is longer because it has to go over so many registers. >A longer data bus implies larger capacitance and longer discharge time, >thus longer processor cycle.... >So the question is: Is it clever to invest in a large register file with >windows or is it better to use the silicon for other circuitry? .... Could you quantify the hit from these issues, or point at some references that show data for this? In any of my competitive analysis, I've never made an issue of it, and generally haven't thought it was an issue....if somebody else proves it is an issue, I won't argue too much! :-) -- -john mashey DISCLAIMER: 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