🚀 go-pugleaf

In article <926@mips.UUCP>, sjc@mips.UUCP (Steve Correll) writes:
> In article <3810002@nucsrl.UUCP>, ram@nucsrl.UUCP (Raman Renu) writes:
> > ...given a fixed number of registers, How many are effectively usable for
> > the register declaration.

> Given a smart compiler, it's often effective to put the 'register'
> declaration on every variable which you happen to know won't be
> referenced by a pointer.  Even if the compiler can't put them all in
> registers, it can sometimes perform other optimizations as a result.

Shouldn't a compiler smart enough to allocate variables to registers be
smart enough to see that a local variable is never the operand of the
& (address-of) operator, and thus cannot be referenced by a pointer?
Both of these tasks seem to require that the procedure be completely
scanned before code generation.

> Given a not-so-smart compiler, which puts variables into registers only
> on command, it's ususally harmless to give too many 'register'
> declarations--but you'd probably better put the most important variables
> first, lest the compiler run out of registers before getting to the
> important ones.

True. Unfortunately if you use inner scopes this isn't always possible.
E.g.

   proc()
   { register int blat, blog, blit;
     ...
     { register int glip, glop, glurp;
       ...
     }
   }

Even if you know exactly the order of priority for these variables to
be put in registers it's not possible to declare them in a way that will
result in the most important being put in registers on any machine, without
modifying the program to not use inner scopes, which could result in other
problems.

By the way, it is typical for 68000 C compilers to have two entirely 
separate sets of register variables, one for pointers, one for data. So
for example:

   register int a,b,c,d,e,f,g,h,i,j,k,l,m;
   register int *p;

Despite all those previous register int's, p probably gets put in a 
register.

    Radford Neal
    The University of Calgary