Disadvantages of register storage class specifier

[aruna]

What is the disadvantage of using register
storage class specifier?

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What is the disadvantage of using register
storage class specifier?

In my opinion, the primary disadvantage is that you can't take the
address of a register variable.

Again, my opinion, but the 'register' storage class doesn't provide much
of an advantage when it is used: the compiler is permitted to ignore it
when selecting placement of variables, compiler optimization of
generated code may do a better job of optimizing placement than the
programmer can, and the language imposes restrictions on the use of
variables defined as register.

- --

Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAj9fCagVFX4UWr64RApRVAKCfs0M3p2yECKZbWJd4Ypw0fj91vwCfRlsu
IT1RBBQIMrWWkTLjc1yVdTY=
=L0q5
-----END PGP SIGNATURE-----

 

[Thomas Stegen]

What is the disadvantage of using register
storage class specifier?

Do your own homework, you will get better answers
in a book than you will get here.

 

[Keith Thompson]

In my opinion, the primary disadvantage is that you can't take the
address of a register variable.

One could argue that that's an advantage. The "register" specifier is
a way of asserting to the compiler that a given variable won't have
its address taken. Theoretically a compiler could use that
information for optimization, even if it doesn't use it for its
original intent (storing the variable in a CPU register).

If my goal were to give the compiler as much information as possible,
I might even use a "register" specifier on *every* variable whose
address isn't taken. But the result wouldn't be pretty, and it
probably wouldn't do much good; any decent modern optimizing compiler
should be able to figure this out for itself.

Again, my opinion, but the 'register' storage class doesn't provide much
of an advantage when it is used: the compiler is permitted to ignore it
when selecting placement of variables, compiler optimization of
generated code may do a better job of optimizing placement than the
programmer can, and the language imposes restrictions on the use of
variables defined as register.

That's certainly the common wisdom, and I suspect compiler
implementers take that into account when deciding how much attention
to pay to "register" specifiers (i.e., not much). I've even read that
"register" can hurt optimization by interfering with the compiler's
own analysis, but I don't know if that's actually true.

 

[Christopher Benson-Manica]

One could argue that that's an advantage. The "register" specifier is
a way of asserting to the compiler that a given variable won't have
its address taken. Theoretically a compiler could use that
information for optimization, even if it doesn't use it for its
original intent (storing the variable in a CPU register).

Setting aside theory, do any real implementations optimize based on
the fact that a given variable's address is never taken, aside from
placing that variable in a register or not?

to pay to "register" specifiers (i.e., not much). I've even read that
"register" can hurt optimization by interfering with the compiler's
own analysis, but I don't know if that's actually true.

I imagine that "register" can only hurt optimization as much as the
compiler lets it. It's a hint that I imagine is nowadays routinely
ignored by compilers.

 

[Christian Bau]

What is the disadvantage of using register
storage class specifier?

It requires typing seven characters, and it disallows usage of the
address operator. In some cases, it causes undefined behaviour.

Now ask for the advantages...

 

[Christian Bau]

Setting aside theory, do any real implementations optimize based on
the fact that a given variable's address is never taken, aside from
placing that variable in a register or not?

First, real implementations are more clever; even if the address of a
variable is taken, it is often possible to determine the set of accesses
to the variable exactly (this would be in practise more important for
C++ compilers + trivial classes + inline functions, but many compilers
implement both C and C++).

Second, if you know exactly all accesses to a variable, then you also
know that there is no aliasing, and that will help a lot. For example:

struct { int x; int y; int z; } t;
int *p;

t.x = 1; *p = 2;
t.y = t.x + 1; *p = 3;
t.z = t.x + t.y + 1; *p = 4;

Even if t.x, t.y and t.z are not in registers, the compiler may be able
to find that t.x, t.y and t.z are set to 1, 2 and 4, and *p needs only
be set once.

 

[Eric Sosman]

What is the disadvantage of using register
storage class specifier?

It requires typing seven characters, [...]

Christian is a *fast* typist ...

 

[Tim Prince]

Setting aside theory, do any real implementations optimize based on
the fact that a given variable's address is never taken, aside from
placing that variable in a register or not?

Yes, if gcc is a real implementation. No, if you don't count registerization
as an optimization. I have bug issues pending against a commercial compiler,
where taking an address inhibits optimization more than it should.

 

[Mark Henning]

What is the disadvantage of using register
storage class specifier?

It requires typing seven characters, [...]

Christian is a *fast* typist ...

Indeed. Can't say much about readability though. Its like
programming while pissed

rgistr cst unsigd sht x;

 

[Dan Pop]

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.

Dan

 

[Case]

It requires typing seven characters, and it disallows usage of the
address operator. In some cases, it causes undefined behaviour.

I would say nine characters.

 

[Dan Pop]

I would say nine characters.

#define regist register

and Christian is right ;-)

Dan

 

[Eric Sosman]

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.

 

[Case -]

#define regist register

and Christian is right ;-)

Dan

But that's 23 (not counting the newline). It should be

#define seven_characters register



Kees/Case