guy@rlgvax.UUCP (Guy Harris) (03/10/84)
This is a spinoff from a comment about speeding up C programs by advising
the C compiler what to put into registers.
The idea is good, but there's one problem with its current implementation;
there's no way to make those hints truly "machine-independent". The problem
is that you want to use all the registers you can (actually, there's even
a tradeoff here; you get extra performance from instructions referencing
registers, but you do have to save and restore those registers, and if you
have complicated expressions you may run out of scratch registers and be
forced to use temporaries in memory), but "all the registers you can" is
machine-dependent. On the PDP-11, "all the registers you can" in the Ritchie
and Johnson compilers is 3; on the VAX-11, it's 6, and on the M68000, it's
(at least on our compiler) 6 registers not containing pointers and four
registers containing pointers. Just declaring everything you can to be
"register" wins only if 1) there are enough registers to satisfy your requests
or 2) the variables that will cause the greatest improvement when put in
registers are assigned to registers first, and the less important ones cause
the compiler to ignore the "register" declaration.
You can sort of rig it to work right, on compilers that assign "register"
variables to registers in the order they encounter them in the source text,
buy putting the "best" candidates first; however, 1) this means you may not
be able to use the "register parameter" feature, 2) it makes your code a
little less readable, and 3) most importantly, it requires you to know what the
compiler does - but what happens if the compiler doesn't work that way?
Writing portable code to use registers efficiently is tricky at times.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guytgg@hou5e.UUCP (03/14/84)
>The idea is good, but there's one problem with its current implementation; >there's no way to make those hints truly "machine-independent". The problem >is that you want to use all the registers you can (actually, there's even >a tradeoff here; you get extra performance from instructions referencing >registers, but you do have to save and restore those registers, and if you >have complicated expressions you may run out of scratch registers and be >forced to use temporaries in memory), but "all the registers you can" is >machine-dependent. On the PDP-11, "all the registers you can" in the Ritchie >and Johnson compilers is 3; on the VAX-11, it's 6, and on the M68000, it's >(at least on our compiler) 6 registers not containing pointers and four >registers containing pointers. Just declaring everything you can to be >"register" wins only if 1) there are enough registers to satisfy your requests >or 2) the variables that will cause the greatest improvement when put in >registers are assigned to registers first, and the less important ones cause >the compiler to ignore the "register" declaration. > > > Guy Harris > {seismo,ihnp4,allegra}!rlgvax!guy No no no - you're taking the meaning of 'register' too literally! It does not mean that the compiler is forced to use a register for these variables, it just means that you're giving it a hint that these variables are more likely to be referenced than other variables. If that means that, for the machine at hand, the variables should be three's complimented and stored in reverse bit order starting at memory location 3fd3.8 (octal) because that is the absolute best place to store an integer for speedy calculations, then the compiler should do that for 'register' variables. Let the compiler worry about what to do if it runs out of registers or other resources. The point is that 'register' exists to differentiate some variables from others so that a compiler can make some reasonable tradeoffs if possible. Making every variable in a program 'register' isn't any good because their *all* important. If you want overall optimization, make a better optimizer. Personally, I think that 'register' should have been changed to 'fast' or something like it long ago... Tom Gulvin ABI - Holmdel
smk@axiom.UUCP (Steven M. Kramer) (03/15/84)
You have to take into acct :
1) # of reg assignment allowed on your machine,
2) cost in terns of saving/restoring regs
as Guy Harris said. I usually order my reg so tthat the most used variable
comes first, so that if my program were ported to a PDP-11, it would
still run sort of fast. I know that's sort of implementation dependent, but
all optimization is that way. On the 68000 port we are using, there is
a difference between address resgister and data registers that ALSO must
be taken into consideration. On the VAX and PDP that's not so, but
using rigister in any machine should keep in mind all of the differences.
The best code would #ifdef the differences (especially if another processor
handled things differently), but few of us (I don't, I can't anticipate
all uses) think that way. So, each new port has to look a register
declarations. Few even use them to begin with. so ANY use is a plus.
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)