Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!uunet!portal!cup.portal.com!bcase
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch
Subject: Re: 80486 vs. 68040 code size
Message-ID: <18109@cup.portal.com>
Date: 8 May 89 17:26:51 GMT
References: <907@aber-cs.UUCP>
Organization: The Portal System (TM)
Lines: 54

>Well, in a long discussion a few months ago in comp.lang.c, nobody has been
>able (in a period of two months) to quote any FIGURES that support this [that
>lots of registers can be used to advantage by compilers.]
>There are plenty of figures though about the average extreme simplicity of
>actual statements/expressions/constructs in algorithmic level languages, which
>does not bode well for the usefulness of large register files.

Um, I, as well as many who read here, can give you at least a few references
that talk about the number of registers that can be put to use.  The average
"extreme simplicity" of individual arithmetic statements is only a part of
what determines the number of registers that can be used.

>You may become less amused after having read some old and half forgotten
>papers, e.g. one by knuth on the complexity of fortran programs, and one that
>appeared in sigplan on the average complexity of C expressions and the
>number of registers needed to optimize them (dated early seventies one and
>late seventies the other, if I remember well -- this is not the machine on
>which I keep all my references, unfortunately).

These findings are relevant only if you want always to load the operands
from memory before executing the expression and always to store the result
to memory after executing the expresson.  If you would like to keep the
source operands and the result around for a while to reduce the number of
memory references, and thereby create an opportunity to increase performance,
then you will want more registers.

>	If John Mashey could give us some of the numbers that MIPS have
>	surely got on where they estimate the knees of the curves for
>	registers for intra and inter statement optimization to be, we would
>	be greatly enlightened (e.g. as to why their register file is so
>	different from that of SPARC and 29K); maybe he has already, and I
>	have missed them.

I believe he has in the past given such numbers, and they are something like
24 to 28 registers, depending on a few variables.  The reason the 29K and
SPARC have larger register files is not because we thought there was vastly
more opportunity for common subexpression elimination or that intra-procedure
register lifetimes are longer than MIPS thinks they are.  The reason has to
do with decreasing procedure call overhead.  For the 29K, in which, unlike
the SPARC, all registers are simultaneously addressable, we (or at least I)
thought that since there is no substitute for registers (that is, they are
much faster, in an earlier pipestage, and have 3x the bandwidth of a plain
old cache), it is not a bad idea to have lots of them.  This might sound
unscientific, but we didn't just say "this feels good, let's do it."

>Moreover on CISC machines that have on chip caches (like the 486 and the
>68040), large register files (whose main use is as a kind of statically
>managed cache -- or stack, ala SPARC) would probably not make a whole lot of
>difference (except perhaps to [understatement of the year] the not
>uninmportant issue of chip component count).

Having the needed operands in the register file is a lot better than having
them in the data cache, unless the cache is triple-ported and in the decode
stage of the pipe.  But then, it is just a large register file....