Register variables...

R L StPeters stpeters at steinmetz.UUCP
Wed Jul 10 05:24:01 AEST 1985


> The 'register'  storage  class  qualifier should generally be *ignored* by a
> good  compiler:  the  compiler  should  place values (and not just variables
> necessarily, but common subexpressions as well) in registers as it sees fit.
> E.g. a  compiler  can  realize  that  a  variable  is used inside a loop and
> generate code accordingly, etc.

Compilers that use register variables as they see fit can add much to the
overhead of function calls due to large register masks.  This was the only
reason we could figure for a friend's program's execution time being about
twice as long when compiled with the VAX-11 C compiler as when compiled
with our Interactive Systems' IS/1 compiler (multiple comparison runs on
the same 11/782/VMS system under the same average load conditions).

His program spent much of its time calling several fairly large procedures
isolated in a module.  These were called thousands of times and usually
simply returned after making one simple comparison, but occasionally they
did something complex.  This happened seldom enough so it mattered little
whether they used register variables.  The DEC-compiled version apparently
spent an awful lot of time just saving and restoring unchanged registers.

I don't know if he ever tested it using the /noptimize qualifier.  He
just went back to the IS/1 compiler.  It ran fast enough.

Personally, I have a problem with compilers that decide on their own
that something I tell them should be *ignored*.  The VAX-11 C compiler's
optimization has made a number of my own procedures not work.  But then
I have a habit of doing in C things that a compiler-writer might think
god intended to be done only in assembly language.

-- 
R. L. St.Peters (Dick)        The "R" is for "Reptile".
uucp: decvax!mcnc!ncsu!uvacs!edison!steinmetz!stpeters (uucp is forever)
arpa: stpeters at ge-crd                                  (federal express)
	"Any opinions expressed by my employer are probably not mine."



More information about the Comp.lang.c mailing list