Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucsfcgl.UUCP
Path: utzoo!linus!decvax!ucbvax!ucsfcgl!arnold
From: arnold@ucsfcgl.UUCP (Ken Arnold%CGL)
Newsgroups: net.lang.c
Subject: Re: register variables
Message-ID: <551@ucsfcgl.UUCP>
Date: Sat, 22-Jun-85 15:38:04 EDT
Article-I.D.: ucsfcgl.551
Posted: Sat Jun 22 15:38:04 1985
Date-Received: Mon, 24-Jun-85 07:32:34 EDT
References: <472@crystal.UUCP>
Reply-To: arnold@ucsfcgl.UUCP (PUT YOUR NAME HERE)
Distribution: net
Organization: UCSF Computer Graphics Lab
Lines: 65

In article <472@crystal.UUCP> shekita@crystal.UUCP writes:
>1) When is it appropriate to declare a variable as a
>   register? I have been told that declaring a variable 
>   as a register can actually result in slower code. Is
>   there a rule of thumb dictating when and when not to
>   declare a variable as a register?

Generally, the only time declaring a variable to be a register
generates slower code is when you declare a parameter to be a
register.  This is because, on most systems, this requires a move from
the stack into a register.  If the variable is rarely used, this
overhead may cost you more than having it in the register saves.

In some degenerate, unpredictable cases a compiler which isn't properly
written will generate worse code for a register variable than a
non-register variable.  I have seen this happen once on a vax.
However, you have no way of prediciting this kind of behavior, and
since someone might fix the compiler, you run a chance of getting worse
code in the future.

Some particularly smart compilers will use unused registers for
storage of intermediate values to avoid recalculating them.  Then you
can hurt yourself by declaring rarely used variables, since it takes
them out of contention for this, but these compilers are VERY rare.

>2) How many variables can be declared as registers on a Vax 780?
>   In general, is there some way to tell how many register variables
>   can be declared?

You have an infinite number of registers.  No, seriously, this is the
way to think about it.  You should declare EVERYTHING which you don't
have to take the address of to be a register.  You can tell old pdp-11
code in UNIX by the fact that they leave off declaraing register
variables after three.  Then, when the code was brought to a vax, which
has five, this potential optimization was lost.  If you declare all
legal variables to be registers, your code ports and takes advantage of
the new machine's resources without added work.

By EVERYTHING I mean just that.  Some machines have floating point
registers and some don't.  Some don't put chars in registers and others
do.  Some don't put in shorts in.  Some put one-word structures in
registers.  Some will someday put multiword structures in registers, if
somebody doesn't already.

Just be somewhat careful to declare things in the order you care
about.  This cuts both ways -- if you move to a machine with fewer
registers than yours, you can loose the most critical register uses in
favor of less critical.  For example, let's posit a two register
machine and the following code

	register int	i, j;

	for (i = 0; ...)
		for (j = 0; ...)

Now, move it to a one register machine, and "j", which is the most
tested variable, is out of a register and "i", which is used less
often, is still in one.  Not what you want.

All this shows is that register allocation should be done by the
compiler, not the user, except in rare circumstances.  Until someone
does a C compiler this way, though, you're stuck with these
techniques.

		Ken Arnold