Re: What is the current situation regarding the C "register" decl?

moss@cs.umass.edu
Fri, 26 Jun 1992 12:43:14 GMT

          From comp.compilers

Related articles
What is the current situation regarding the C "register" decl? boles@cayman.asg.arlut.utexas.edu (David Boles) (1992-06-23)
Re: What is the current situation regarding the C "register" decl? sasghm@unx.sas.com (Gary Merrill) (1992-06-24)
Re: What is the current situation regarding the C "register" decl? moss@cs.umass.edu (1992-06-26)
| List of all articles for this month |

Newsgroups: comp.compilers
From: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Date: Fri, 26 Jun 1992 12:43:14 GMT
Keywords: registers, optimize
References: 92-06-118 92-06-122

I agree that *most of the time* an optimizing compiler is in a better
position to make informed decisions about register use. There are
occasions where the compiler can be wrong. The case I usually trot out is
the Smalltalk interpreter we have written in C. The general structure is a
loop containing a 256-way branch (*) based on the next byte code
("instruction") to be executed. Compilers try to make some guess as to
frequency of execution of different parts of the code, but in this case we
know the statistics much better and would like like to force certain of
the interpreter's "registers" into actual machine registers. This tuning
tends to be a bit platform specific (i.e., we may say different things,
via ifdefs, depending on platform) since what we can achieve depends on
the number of available registers. Note that this makes sense only for
heavily executed programs and only for their innermost loops. If the
compiler could be presented with statistics it might remove most of the
need for this kind of messing with declarations (we frequently use
something stronger than just a register declaration, namely a gcc asm that
*forces* global allocation of a particular quantity to a particular
register). Using real statistics gathered from profiling seems to be more
and more popular, so maybe we won't have to do this any more after a
while.


(*) Actually, to avoid *two jumps* per byte code, one for the switch and
one to go back to the top of the loop, we now have a 256 entry label array
(gcc 2.x supports labels as (void *) data items) and the end of the code
for each byte code has a computed goto. This sped things up by about 15%,
the single largest performance increment we have ever had in tuning this
code.
--


J. Eliot B. Moss, Associate Professor
Department of Computer Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.