🚀 go-pugleaf

In article <10979@polyslo.CalPoly.EDU> cquenel@polyslo.CalPoly.EDU (24 more
school days) writes:
    
    	Hahahahah ha ha ha ha ha. 
    	Oh. excuse me. (chuckle)
    	I can't help myself.

This is fairly evident :-] :-] ....
    
    	Highly optimizing compilers have long been able to make very
    	good use of more than four registers.

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 and
other urban legends (e.g. Elvis is alive and designed the Z80000 :->). 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.

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).

Even some of the RISC guys, and some that do a great deal of inter-expression
register assignments (which I don't like at all -- long life "register"!),
like MIPS, don't see a great advantage in extravagant register file sizes.

	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.

Sixteen registers in total, of which some are dedicated, some are assigned
to global values (I remember having seen papers that say that keeping in two
registers the constants 0 and 1 may pay big on some/many architectures),
some are used for "register" variables, may be reckoned to be plenty enough,
and don't leave much more than four for scratch usage. Eight (e.g. the 486)
starts to be a bit constraining, admittedly, for getting four scratch
registers and soem for "register" variables.

As to some small bit of available evidence, it is not very controversial
that the 386 is usually a tad faster than the 68020 with roughly equivalent
system technology (e.g. a cached 386 at 20Mhz tipically beats a cached 68020
at 25 Mhz under gcc), and code size is a tad smaller as well.  This may not
mean much, may not be just *because* it has less registers, but it seems to
indicate that at least the smaller number of registers does not hurt too
much.

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).
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk