rtrauben@cortex.Eng.Sun.COM (Richard Trauben) (01/06/91)
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..... -richard
mash@mips.COM (John Mashey) (01/08/91)
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