Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!seibel
From: seibel@cgl.ucsf.edu (George Seibel)
Newsgroups: comp.arch
Subject: Re: Register usage [was Re: 80486 vs. 68040 code size]
Message-ID: <11582@cgl.ucsf.EDU>
Date: 8 May 89 05:26:02 GMT
References: <907@aber-cs.UUCP> <25546@amdcad.AMD.COM>
Sender: daemon@cgl.ucsf.edu
Reply-To: seibel@hegel.mmwb.ucsf.edu (George Seibel)
Distribution: eunet,world
Organization: Computer Graphics Lab, UCSF
Lines: 37

In article <25546@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
>In article <907@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>| In article <10979@polyslo.CalPoly.EDU> cquenel@polyslo.CalPoly.EDU writes:

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

>OK, here are some figures to play with:
 [...]
>A static analysis of 495 functions shows that an average of 6.6 global
>registers and an average of 7.0 local registers are used per function,
>with the following register-use histogram: (ain't 'awk' wonderful? ;-)

Thanks for the data, Tim.   I applaud the analysis of real world code
in computer design, but I'm concerned that any large database of code
might be heavily stacked with code that just doesn't matter.   Many
millions of dollars of supercomputer time are burned yearly at the
NSF centers;  A handful of applications programs account for much of
this time.   If you profile these applications you typically find a
small fraction of the code is responsible for a large fraction of the
cpu time.   I have looked at the assembly code for some of these
computational kernals, and said, "Damn! look at all these spills!"
Eight (vector) registers was not "enough" in the cases I looked at.

My main point, however, is that modern micros are already fast enough
for much of what we do.  If someone designs a machine to run vi ten
times faster than a 68030, I'm not going to be impressed.  As machines
get faster, the code database from which one should design either gets
smaller, since there are less existing functions that still represent
bottlenecks, or it gets harder to build, because it becomes more heavily
weighted with the code we would *like* to write, except that machines
aren't yet fast enough to run it.

George Seibel, UCSF