Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Number of registers
Message-ID: <44564@mips.mips.COM>
Date: 7 Jan 91 19:14:08 GMT
References: <zillions> <5336@exodus.Eng.Sun.COM>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 40

In article <5336@exodus.Eng.Sun.COM> rtrauben@cortex.Eng.Sun.COM (Richard Trauben) writes:
>If Intel really wanted to compensate for the limited number of 
>registers which force local operands to spill out to the stack
>in memory, they could always add a small on-chip multi-port stack
>cache (ala' CRISP) without breaking the ISA. I'm sure that they
>have already studied this and come to their own conclusions. 
>Contrary to popular belief, folks who actually do the work do
>read conference proceedings papers.....

Actually, I don't think this works in this direction, or at least it may
not do much good (which maybe what Richard is saying).  However,
it needs some explanation, because the two cases are very different.

If an ISA was crafted that includes lots of registers, the compilers assume
they exist, and generates code to use them.  In this case, they seldom, if ever,
need to generate "spill code" to save intermediate results due to lack of
registers.  (Chapter 3.7 of hennessy&Patterson is relevant here).
It may be that hardware or hardware+software are really handling the spills
behind the compiler's back, and clearly, more registers may help.

If you have an ISA that has few registers, the compiler MUST generate
spill code, and even if you design in an invisible stack cache,
THE SPILL CODE DOESN'T GO AWAY - it still uses issue cycles.

Now, a small stack cache added to an X86 might have made sense for
a 286 or 386, i.e., you could perhaps capture a reasonable number of
references with a small stack cache, although the same size on-chip
I-cache would probably be more helpful.  However, by the time you get
4K-8K bytes of on-chip cache, I'd guess that the data part of it subsumes
the stack-cache idea anyway, and then is generally more useful, although
the spill code STILL doesn't go away.

Anyway, one should trust nothing but serious simulations (of which the
above discussion was not), but like Richard's comments sugest,
it wouldn't surprise me that a stack cache was a bad idea for an X86.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086