Limit on maximum number of register variable in C program

[alakesh.haloi]

Hi All
Is there a limit on the number of register variables that can be
declared and initialized in a C program on a particular hardware
platform? If you define more number of register variables than the
processor has, how is it handled by the C compiler?

regards

 

[dandelion]

Hi All
Is there a limit on the number of register variables that can be
declared and initialized in a C program on a particular hardware
platform?

No. However, the compiler is not obliged to honour any of them.

If you define more number of register variables than the
processor has, how is it handled by the C compiler?

By ignoring the "register" keyword for most/all of the variables you
declared that way.

Using the "register" keyword is seldomly very desirable. In most cases, an
optimizing compiler
will put variables in a register anyway (if it can, that is). Hence the
keyword 'volatile" which explicitly prevents this.

The only case where "register" is handly, is when you want to pass a hint to
the compiler about what to optimize.

 

[James McIninch]

<posted & mailed>

The register keyword is merely a hint to the compiler. it doesn't force a
variable into a register. So, there's no limit to what can be declared
register, or how many variables. The compiler will simply choose some and
ignore the rest.

 

[Keith Thompson]

No. However, the compiler is not obliged to honour any of them.


By ignoring the "register" keyword for most/all of the variables you
declared that way.

It can't completely ignore it; it still has to forbid (or at least
issue a diagnostic for) any attempt to take the address of a
register-qualified variable.

 

[Ben Pfaff]

It can't completely ignore it; it still has to forbid (or at least
issue a diagnostic for) any attempt to take the address of a
register-qualified variable.

A lousy implementation might issue a warning for taking the
address of *any* variable, I suppose.

 

[Dave Vandervies]

A lousy implementation might issue a warning for taking the
address of *any* variable, I suppose.

A rather more reasonable way to avoid doing the work of recognizing this
case is to issue a warning any time it sees the register keyword.


dave

 

[Alan Balmer]

A rather more reasonable way to avoid doing the work of recognizing this
case is to issue a warning any time it sees the register keyword.

Yechh. I have to work with a (HP-UX) compiler which issues a warning
every time it sees "const", whether or not it's used properly.

 

[Peter Nilsson]

The standard puts it best: "A declaration of an identifier for an
object with storage-class specifier register suggests that access
to the object be as fast as possible. The extent to which such
suggestions are effective is implementation-defined."

So, register is simply a hint to the compiler, although the compiler
is free to ignore the hind.

No. However, the compiler is not obliged to honour any of them.


By ignoring the "register" keyword for most/all of the variables you
declared that way.

Using the "register" keyword is seldomly very desirable.

That's overstating it.

In most cases, an optimizing compiler will put variables in a register
anyway (if it can, that is).
True.

Hence the keyword 'volatile" which
explicitly prevents this.

No. The volatile keyword is a type qualifier, not a storage specifier.
It serves a different purpose. They are not mutually exclusive.

#include <stdio.h>

int main()
{
register volatile int x = 42;
printf("%d\n", x);
return 0;
}

 

[Dave Vandervies]

[discussing appropriate diagnostics for an implementation that ignores
`register']

Yechh. I have to work with a (HP-UX) compiler which issues a warning
every time it sees "const", whether or not it's used properly.

This is much less unreasonable for register than it is for const, just
because of the way the two are used.

But even for const... would you prefer that the compiler warned every
time the code modified an object, because that object could have been
declared const and the compiler knew it ignored the const if there was
one and might therefore have missed a constraint violation?


dave

--
Dave Vandervies (e-mail address removed)

Well, it's rather far from rocket science, mixing it up....

Actually, I hear it's a primary ingredient in the space shuttle's solid rocket
boosters. --Ingvar the Grey and Phillip Jones in the Scary Devil Monastery

 

[Richard Bos]

This is much less unreasonable for register than it is for const, just
because of the way the two are used.

But even for const... would you prefer that the compiler warned every
time the code modified an object, because that object could have been
declared const and the compiler knew it ignored the const if there was
one and might therefore have missed a constraint violation?

I'd rather that it warn every time I assigned away the const, or assign
to a known-const object. The compiler _knows_ which objects are const;
it also knows when I do something unsafe with one of them.

Richard

 

[Dave Vandervies]

I'd rather that it warn every time I assigned away the const, or assign
to a known-const object. The compiler _knows_ which objects are const;
it also knows when I do something unsafe with one of them.

Well, yeah. But if the compiler had good reasons for ignoring const[1]
but still wanted to be conforming (and therefore needed to do something
about missing possible constraint violations by ignoring it), which of the
options that doesn't involve checking it for semantics would you prefer?


dave

[1] I have no idea what kind of good reasons a compiler might have for
ignoring const, but this discussion started with an optimizing
compiler ignoring register, and there are good reasons for that -
any self-respecting optimizer will do its own register allocation
and should handle it at least as well as the programmer would.

 

[Randy Howard]

Yechh. I have to work with a (HP-UX) compiler which issues a warning
every time it sees "const", whether or not it's used properly.

Well, if you've ever used gcc with -Wwrite-strings then you know
the pain of an overly noisy compiler with respect to const. It's
basically unbearable on any large project that hasn't been through
the rigors of "const poisoning" already.

 

[CBFalconer]

(e-mail address removed) says...


Well, if you've ever used gcc with -Wwrite-strings then you know
the pain of an overly noisy compiler with respect to const. It's
basically unbearable on any large project that hasn't been through
the rigors of "const poisoning" already.

I routinely have -Wwrite-strings set (via an alias) and never see
anything. If something turns up there is a fault, and it should be
corrected.

 

[Randy Howard]

I routinely have -Wwrite-strings set (via an alias) and never see
anything. If something turns up there is a fault, and it should be
corrected.

For your own code, sure. Far too many (or not enough, depending upon
what you think of const I suppose) don't think that generating a
warning for this is of much value...

#include <stdio.h>
#include <stdlib.h>

void doit(char *outstr)
{
if (outstr)
printf("%s\n", outstr);
else
puts("bug: (null) passed to doit()");
}

int main(void)
{
doit("This is a test.");
return EXIT_SUCCESS;
}

gcc will spit out:
foo.c:16: warning: passing arg 1 of 'doit' discards qualifier from
pointer target type

Now, shoving a const in there will fix it, but for large existing
projects, that might mean hundreds of minor changes just to make
the compiler shut up. The cascade of const requirements (aka
const poisoning) is often not worth it. More than a few coding
standards say not to use it at all.

I am not saying it shouldn't ever be used, but opinions on its
implicit wonderfulness vary widely.

 

[Alan Balmer]

[discussing appropriate diagnostics for an implementation that ignores
`register']

Yechh. I have to work with a (HP-UX) compiler which issues a warning
every time it sees "const", whether or not it's used properly.

This is much less unreasonable for register than it is for const, just
because of the way the two are used.

But even for const... would you prefer that the compiler warned every
time the code modified an object, because that object could have been
declared const and the compiler knew it ignored the const if there was
one and might therefore have missed a constraint violation?

I read the above twice, and apparently fail to parse it correctly.
Anyway, I would prefer that the compiler complain if constness is
violated, not otherwise. The warning I'm talking about is to the
effect that "const objects may be stored in read-only memory, and
attempts to modify them may fail." Regardless of whether any such
attempt was made. The warning has no relation to the code - it's just
spitting out a line from the programming manual.

 

[Dave Vandervies]

[drifting over to const from a discussion of ignoring register]

I read the above twice, and apparently fail to parse it correctly.
Anyway, I would prefer that the compiler complain if constness is
violated, not otherwise. The warning I'm talking about is to the
effect that "const objects may be stored in read-only memory, and
attempts to modify them may fail." Regardless of whether any such
attempt was made. The warning has no relation to the code - it's just
spitting out a line from the programming manual.

It sounds to me like that's the compiler's way of saying "I don't do
semantics checking on const, so I might be missing a constraint violation,
so here's a diagnostic just in case", though somewhat less so now that
I've seen the actual text of the warning. (Unless it also complains
about code that actually does violate the constraints on const objects?)

Doing the equivalent with register, as I was suggesting (now snipped), is
actually a sensible thing to do for a completely-and-correctly implemented
compiler - any self-respecting optimizing compiler will ignore it during
code generation anyways, and the constraints on register objects don't
really serve any useful purpose in correctness checking.

For const, doing this means that the compiler implementor was either
too lazy or (more likely) too rushed to properly implement const (I
suspect by adding it to a pre-ANSI compiler?). Not a Good Thing, but
not entirely unreasonable either.

So my question was, would you prefer this behavior (warning when it
sees a keyword it ignores) over the behavior Ben suggested (warning
when a constraint would be violated if the object being acted on had
the storage class defined by the keyword that was being ignored)?

--------
void foo(void)
{
int a;

/*I was talking about a warning here
("register keyword ignored")
*/
register int b;

/*Ben was talking about a warning here
("register keyword may have been ignored in declaration of operand of &")
*/
do_something_with(&a);

/*This is a constraint violation; either warning above will give
the required diagnostic when this happens as well as in cases
where it doesn't
*/
do_something_with(&b);
}
--------

Note especially that I'm not claiming either behavior is "good" for
const, just that one is more reasonable than the other, for the same
reason it's more reasonable for register.


dave

 

[CBFalconer]

(e-mail address removed) says...

For your own code, sure. Far too many (or not enough, depending
upon what you think of const I suppose) don't think that generating
a warning for this is of much value...

#include <stdio.h>
#include <stdlib.h>

void doit(char *outstr)
{
if (outstr)
printf("%s\n", outstr);
else
puts("bug: (null) passed to doit()");
}

int main(void)
{
doit("This is a test.");
return EXIT_SUCCESS;
}

gcc will spit out:
foo.c:16: warning: passing arg 1 of 'doit' discards qualifier from
pointer target type

Now, shoving a const in there will fix it, but for large existing
projects, that might mean hundreds of minor changes just to make
the compiler shut up. The cascade of const requirements (aka
const poisoning) is often not worth it. More than a few coding
standards say not to use it at all.

I am not saying it shouldn't ever be used, but opinions on its
implicit wonderfulness vary widely.

I wasn't thinking of that sort of propagation when I wrote the
comment, but more of usage in statements. I can see the urge, but
any such code standard has its head well up, IMO. The process of
fixing things is probably not pressing and can be done mechanically
at suitable moments. The result is likely to expose some real
problems.

The coding standards should insist on -Wwrite-strings for any new
code.