Re: register variables in C.

Dave Howell <dave.howell@ColumbiaSC.NCR.COM> writes:
> High C took this 'feature' away as it's use/cost analysis does not honor
> the 'register' qualifier. We wondered if this wasn't a bad idea,
> especially in the Unix kernel where our developers have been used to
> tuning the code with knowlegable use of the 'register' qualifier.


GNU GCC versions 1.xx (and I believe the 2.xx flavor as well) also ignore
"register" qualifiers. I know of at least one large graphics system which
must compile efficiently on a number of compilers, including GCC, and thus
includes in its drawing macros a primitive something like


#define L do{
#define R }while(0);
#define HIPRI(X) L L L L L L L L X R R R R R R R R


used like


HIPRI( y = x; )


which seems to confuse GCC into doing the right thing in some cases. In
one case this resulted in a speedup of 2 or 3, if memory serves.


It's not clear what the right behavior is: if the code was intended to be
compiled with ancient PCC, probably there are way too many register
declarations to generate near-optimal code on a more modern compiler if
the modern compiler honors them all. Probably C should have had a more
informative mechanism for indicating critical variables and paths than
just "register," but it's too late for that now. Perhaps the best thing
for now would be for C compiler vendors to agree on a name for a pragma
which would make their allocators honor explicit register declarations
wherever possible...


Bart Massey
bart@cs.uoregon.edu
[I've heard of compilers which use a weighting function that combines
register declarations and usage statistics to decide what to put in
registers. It seems pretty pitiful if you have to add a pragma that
says "I'm really serious about registers." I'd rather say that register
means register and if you want the compiler to make its own decisions,
say -Dregister=auto. -John]
--

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