Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!linac!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.lang.c
Subject: Re: May too many register variables hurt? (was Re: Novice question.)
Message-ID: <976@mwtech.UUCP>
Date: 26 Nov 90 17:05:38 GMT
References: <1990Nov14.010511.7241@ux1.cso.uiuc.edu> <965@demott.COM> <967@mwtech.UUCP> <1990Nov21.221908.19871@cbnewsm.att.com>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 82

In article <967@mwtech.UUCP>, martin@mwtech.UUCP I gave recommendations
for using the `register' attribut. If had known the number of followups
on this I had possibly chosen a more careful wording.

Most of my original posting should treat the case where you try to make
things "right" even in case your software gets ported to some environment
you don't know while you write the program. (To some degree this could
be compared to the recommendation: "Never assume the bit pattern of the
NULL-pointer is all zero", even if you currently work only on machines
where this is true.)

In short, I tried to warn the reader that everything which exceeds two
register declarations in the outmost block of a function *could* result in
code that performed worse than with fewer declarations (hence the subject).
Thinking a bit more about it I should rather have recommended to make
sure that "the two variables for which the register attribute is most
important should be declared as the first ones in the outmost block". If
we trust the compiler getting right what K&R says wrt to the significance
of the order of register declarations, using more register declarations
in the outmost block should be OK. (But see also the last paragraph.)

Any assumptions made about a maximum number of available registers is
allways somehow influenced by the hardware one has in mind. (Maybe I'm
still influenced here by the machine which was the first one I used with
C, the 6809 :-)). If todays hardware commonly supports five registers,
there is no point not using them. (Another followup by Doug Gwyn in this
thread shows an elegant way how register usage can be fine-tuned using
the preprocessor.)

In article <1990Nov21.221908.19871@cbnewsm.att.com> lfd@cbnewsm.att.com
(leland.f.derbenwick) answered:

>[...] use register declarations generously -- typically
>from 1 up to 4 or 5 in each function will _help_, not hurt.

What is so different from Lee Derbenwick's recommendations compared to
mine, except that the `portability range' he has in mind includes machines
with 4 or 5 registers? Of course, the number 4 or 5 may be more appropriate
to "typical" hardware today, and if the access-frequency of the five
variables in question is about the same *and* their logical lifetime
perfectly overlaps, there is nothing to gain from *not* declaring them
with `register' storage class. I admitt that strictly following my
original advice to use no more than two register declarations will
result in slower code then.

>Martin Weitzel's advice not to declare inner-block variables as register
>is good -- some un-smart compilers ignore them; others limit their
>optimizizations near them; some handle them well.  It's a gamble.

I'm quite glad to read this :-), as Doug Gwyn in his first followup to my
original article wrote in contrary and recommended using `register' within
blocks as for PCC-like compilers this will even allow sharing registers.
It really seems to be a gamble ... and as in every gamble you may loose.

If we now leave the question of "how much exactly", there remains the
more general problem: Should a programmer limit the number of register
declarations, or, to drive it to the extreme, should he or she simply
declare every `auto'-variable with attribute `register' - provided there's
no need to take the adress? Given that the access frequency for all those
variable differs considerably - and this is true in most every case - a
programmer who tunes a function for execution speed must care to get
the `right' variables into registers.

>Using register declarations will _never_ interfere with a smart
>optimizing compiler. [...]

IMHO I never wrote so, but maybe that was not meant as an objection.

Generally I still tend to see registers as a scarce resource. Given that in
most programs only very small parts have considerable influence to overall
performance, and further assuming the situation where I try to put in
optimizations for target environments I do not yet know, I think it's no
bad idea - if with small changes to the algorithm possible - to concentrate
high access frequency to very few variables; often the set of such variables
will not be the same in different parts of the function I'm about to optimize.
Then IMHO it's better to only use a limited number of register variables,
declared at function block level, and to manually reuse them, as to depend
on the compiler to reuse register variables in nested blocks. (Note that
I carefully avoided to mention an exact number in this paragraph. It is up to
the reader to replace `few' and `limited' with 2, 5, 10, or whatever :-))
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83