John Levine writes:>[Use them, let the compiler decide with `-Dregister=auto'.]

You might want to define register to nothing in case `auto' forces vars to
memory for some reason. This approach is all-or-nothing which is
undesirable since different compilers & architectures have different
needs. I recommend `register' for the most important variables and and
use other #defines for the remainder [Cannon et. al]:

register int x1;
register int y1;
REGISTER int x2;
REGISTER int y2;

This approach can tell compiler A `x1' and `y1' belong in registers and
can tell compiler B that `x2' and `y2' also belong in registers. It also
avoids telling `A' that `x2' and `y2' belong in registers, which keeps
compiler A from being swamped with register declarations. That might be
important on machines with few registers. It also helps the person
porting/maintaining the code in deciding which things the original
programmer believes are most important.

In writing code for several platforms you may need to define REGISTER,
REGISTER2, etc., to cover the various targets.

I believe that C programmers who are tuning programs should use `register'
and REGISTER and so on because it works in practice and documents
performance tuning. `register' should be used when the situation demands
it; it shouldn't be used gratuitously (nor should `REGISTER' and so on).

I don't recall: the original question could have been ``should I use
`register'?'' or ``should my compiler recognize `register'?'' As a
programmer, I am willing to use a compiler that ignores register
declarations (e.g., GNU CC) because it does a good job in general and
because register allocation is just one of many tuning problems. I would
be happier still if it recognized `register', as I could always turn it
off (-Dregister) but could use it when the situation demands.