Dan Pop wrote:
In <a2**************************@posting.google.com > ar********@yahoo.co.in (aruna) writes:
What is the disadvantage of using register storage class specifier?
The same as its advantage: the compiler might take it seriously.
If the compiler is good at performing optimisations on its own, this
is a disadvantage. If the compiler doesn't even try to optimise, this is
an advantage.
To a good optimising compiler, forcing a variable to be kept in a register
for the whole duration of a function's execution is usually a disadvantage
because it can decide better when keeping that variable in a register
makes sense. Fortunately, such compilers usually ignore this part of the
register keyword semantics and only retain the "no unary & operator" bit.
Further to Dan's point, I've seen code that was "pessimized"
by over-enthusiastic use of `register'. The platform in question
had only a few "scratch registers," and any additional registers
the compiler chose to use had to be saved and restored at function
entry and exit. When the excessive `register' declarations forced
virtually all the local variables into registers, the compiler had
to generate the extra code and memory references to make the extra
registers available. Not a good trade-off for a variable that was
only going to be referenced two or three times ...
In the Early Days when compilers had less memory and fewer
CPU cycles to spend on analyzing and optimizing the code, the
`register' keyword could be useful. Even then, though, it was
"non-portable" in the sense that you didn't really know what effect
it would have on different target platforms. On a register-rich
machine it might pay to use a lot of `register' variables, but the
same tactic could (as recounted above) just as well be harmful.
I once ran across a body of code that tried to accommodate this
difference with definitions like
#ifdef MACHINE_A /* a register-rich machine */
#define REGISTER1 register
#define REGISTER2 register
#define REGISTER3 register
#define REGISTER4 register
#endif
#ifdef MACHINE_B /* a register-poor machine */
#define REGISTER1 register
#define REGISTER2 /* nil */
#define REGISTER3 /* nil */
#define REGISTER4 /* nil */
#endif
.... and then you'd declare the "most important" variable in a
function as `REGISTER1', the "runner-up" as `REGISTER2', and so
on. I don't know how effective the approach actually turned out
to be (I didn't spend much time with the code in question), but
I'm glad such shenanigans have become mostly superfluous.
--
Er*********@sun.com