Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC (was The NeXT problem)
Message-ID: <7041@winchester.mips.COM>
Date: 26 Oct 88 18:12:39 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>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 27

In article <469@oracle.UUCP> csimmons@oracle.UUCP (Charles Simmons) writes:

>If I remember the arguments from MIPS correctly (want to help me out
>John?), there's a stronger objection to multiple-window-register-files.
>I think it's something to the effect that register-windows cause the
>load/store access time to be slower.  I think there also may be some
>argument that a good compiler makes multiple-windows relatively
>unnecessary.

1) Register-windows make load/store access slower: I don't particularly
believe this.  I believe that people sometimes think that windows
may reduce the numbers of loads and stores enough that they think
they can get away with slower loads and stores.  I believe that whether
that's true or not depends on the application; it certainly is not true
for some applications.  As far as I know, the slower loads/stores on
existing SPARCs has nothing to do with having windows, but with the
cache design, and is not intrinsic to the architecture, but rather
the implementation.

2) Good compilers + enough registers do reduce the benefits gained
by register windows; over many benchmarks, we find that the average
number of registers saved/restored is about 1.5-2.
-- 
-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