Register storage type

[Keith Thompson]

Keith Thompson writes: [...]

Always remember that C and C++ are two different languages. The C++
semantics for "register" differ from the C semantics.

<OT>
C++ 2003 7.1.1p3:
A register specifier has the same semantics as an auto specifier
together with a hint to the implementation that the object so
declared will be heavily used. [Note: the hint can be ignored and in
most implementations it will be ignored if the address of the object
is taken. —end note]
</OT>

That's interesting, although I don't think it really explains it - I
normally use g++ in C mode because it gives some extra type checking, eg
prevents implicit typecasting of pointers.

I don't believe g++ has a C mode. g++ and gcc are part of the same
compiler collection; g++ is the C++ compiler, and gcc is the C compiler.

I suppose you mean that you use g++ to compile C code, but as you've
seen, this doesn't always work.

(OH, and you mean "implicit conversions". Casts are always explicit.)

Personally I think the C++ way is better than the C way - it avoids
problems if you try to assign more register variables than the machine
has registers available, effectively in C++ it sounds like the compiler
can "fall back" to discarding the register specification and treating it
like a normal stack variable should there be no register available.

I use the register keyword to tell the compiler that a variable is used a
lot eg as a loop index. What I "really want" is for the compiler to
optimize access to that variable - putting it in a register is only a
means to an end!

"register" is a relic of earlier times with less intelligent optimizing
compilers. The compiler can figure out for itself that a variable is
used heavily, especially a local variable (which is all you can apply
"register" to anyway).

 

[Stephen Sprunk]

Always remember that C and C++ are two different languages. The C++
semantics for "register" differ from the C semantics.

<OT>
C++ 2003 7.1.1p3:
A register specifier has the same semantics as an auto specifier
together with a hint to the implementation that the object so
declared will be heavily used. [Note: the hint can be ignored and in
most implementations it will be ignored if the address of the object
is taken. —end note]
</OT>

That's interesting, although I don't think it really explains it - I
normally use g++ in C mode because it gives some extra type checking, eg
prevents implicit typecasting of pointers.

"Typecasting" is something done to actors, not pointers.

There is no such thing as an "implicit cast"; all casts are explicit
(conversions). ITYM "implicit conversion".

Personally I think the C++ way is better than the C way - it avoids
problems if you try to assign more register variables than the machine
has registers available, effectively in C++ it sounds like the compiler
can "fall back" to discarding the register specification and treating it
like a normal stack variable should there be no register available.

In that respect, there is no difference. The "register" class is just a
hint in both languages. The compiler is free to ignore it when
allocating registers--if the target even _has_ registers.

The only difference I can see, based on the text quoted above, is that
taking the address of a register variable in C++ implicitly changes it
to an auto variable but is an error in C.

I use the register keyword to tell the compiler that a variable is used a
lot eg as a loop index. What I "really want" is for the compiler to
optimize access to that variable - putting it in a register is only a
means to an end!

Modern compilers should figure that out on their own. If your doesn't,
you would be better served by getting a better one than by cluttering
your code with micro-optimizations that make it harder for your primary
audience, i.e. humans, to understand.

S

 

[Angel]

Personally I think the C++ way is better than the C way - it avoids
problems if you try to assign more register variables than the machine
has registers available, effectively in C++ it sounds like the compiler
can "fall back" to discarding the register specification and treating it
like a normal stack variable should there be no register available.

You weren't paying attention earlier. The compiler can and will ignore
the "register" specification _whenever_ _it_ _wants_. There is no such
thing as running out of registers, and no bad stuff will happen if there
are less registers than there are variables with the "register"
specification.

I use the register keyword to tell the compiler that a variable is used a
lot eg as a loop index. What I "really want" is for the compiler to
optimize access to that variable - putting it in a register is only a
means to an end!

Why are you so focussed on these micro-optimizations anyway? Let the
compiler figure it out, modern compilers are smart enough to do it on
their own for all but a few very limited cases.

 

[Eric Sosman]

You weren't paying attention earlier. The compiler can and will ignore
the "register" specification _whenever_ _it_ _wants_. There is no such
thing as running out of registers, and no bad stuff will happen if there
are less registers than there are variables with the "register"
specification.

Back in the day when compilers paid serious attention to `register',
"bad stuff" could indeed happen. I recall two unpleasantesses:

- The compiler might dutifully dedicate CPU registers to variables,
making them unavailable for other uses. This could cause even
fairly simple expressions to fail to compile, if too few CPU
registers remained to hold the intermediate results.

- The compiler might generate extra code to save and restore the
contents of registers dedicated to variables, or to deal with
register scarcity for intermediate expression results. This
could easily slow things down by more than register-residence
for the variables could speed them up.

When compilers had to run in limited memory on slow machines,
they could not afford the kind of analysis they've been doing as a
matter of routine for the last twenty or twenty-five years. In those
days, `register' was sometimes helpful -- although even then it was
quite tricky to employ it well. It was a portable construct with a
non-portable effect.

Why are you so focussed on these micro-optimizations anyway? Let the
compiler figure it out, modern compilers are smart enough to do it on
their own for all but a few very limited cases.

He's already been told this, by multiple people, but he's not
listening.

 

[Jens]

"register" is a relic of earlier times with less intelligent optimizing
compilers.  The compiler can figure out for itself that a variable is
used heavily, especially a local variable (which is all you can apply
"register" to anyway).

I think everybody here gets the sense of register the wrong way. It is
a contract with the compiler that we will not take the address of a
variable and that we ask him to tell us when we do so. So this is a
kind of compile time assertion, not more and not less.

 

[Seebs]

Back in the day when compilers paid serious attention to `register',
"bad stuff" could indeed happen. I recall two unpleasantesses:

- The compiler might dutifully dedicate CPU registers to variables,
making them unavailable for other uses. This could cause even
fairly simple expressions to fail to compile, if too few CPU
registers remained to hold the intermediate results.

In fact, I've seen a modern compiler do this within the last couple of
years, though it was from something a bit more elaborate than just
"register". There exist circumstances under which one popular C library
can be induced to cause horrible compiler failures on x86 because it inlines
string routines in ways that chew up registers.

-s

 

[James Kuyper]

I think everybody here gets the sense of register the wrong way. It is
a contract with the compiler that we will not take the address of a
variable and that we ask him to tell us when we do so. So this is a
kind of compile time assertion, not more and not less.

That's the only practical effect of 'register', but that's not it's
intended purpose.

 

[David Thompson]

Free Willy <[email protected]> writes:

I don't believe g++ has a C mode. g++ and gcc are part of the same
compiler collection; g++ is the C++ compiler, and gcc is the C compiler.

Actually both 'gcc' and 'g++' are only the toplevel drivers, although
they often come packaged with particular underlying compilers
(and sometimes with binutils as well). In particular, *both* 'gcc' and
'g++' can *compile* C or C++ or a mixture; in fact they can also
*compile* ObjC, Fortran (77+ or ~95 depending on version), and Ada if
those compilers are included in the build/package(s).

The difference is in linking (or equivalent): any driver can link C,
but only 'g++' does the additional libraries etc. for C++, only
'gfortran' does Fortran, only 'gnatbind' does Ada. If you want to
combine say Fortan + C++ (+ C) you have to fiddle it yourself.

The decision which compiler to use for each sourcefile is normally
based on the extension (you can override with -x) and on Windows with
case-insensitive filenames the treatment of .c varies -- at least for
mingw; I believe the same is true for cygwin but haven't tried it.

I suppose you mean that you use g++ to compile C code, but as you've
seen, this doesn't always work.

So on Windows g++ foo.c actually compiles as C++. If that source is in
the 'better C' subset of C++, it works and uses C++ rules. As has been
repeatedly discussed here, that subset is not all of C, but it is
quite enough to IMO-reasonably handle any IMO-reasonable program.

 

[Tim Rentsch]

Back in the day when compilers paid serious attention to `register',
"bad stuff" could indeed happen. I recall two unpleasantesses:

- The compiler might dutifully dedicate CPU registers to variables,
making them unavailable for other uses. This could cause even
fairly simple expressions to fail to compile, if too few CPU
registers remained to hold the intermediate results.

In fact, I've seen a modern compiler do this within the last couple of
years, [snip]

Whew, that's a relief... If you had seen a modern compiler
do this, say, 25 years ago, that would have fairly drastic
implications for the laws of physics.

 

[Seebs]

Whew, that's a relief... If you had seen a modern compiler
do this, say, 25 years ago, that would have fairly drastic
implications for the laws of physics.

No, just linguistics. Actually, there are fields in which it would be
perfectly ordinary for a modern thing to have happened 25 years ago,
and fairly shocking for it to have happened this year, because "modern"
got attached to an absolute period rather than remaining a general term
for "the current time frame". Why? Because people are crazy.

-s

 

[Tim Rentsch]

No, just linguistics. Actually, there are fields in which it would be
perfectly ordinary for a modern thing to have happened 25 years ago,
and fairly shocking for it to have happened this year, because "modern"
got attached to an absolute period rather than remaining a general term
for "the current time frame". Why? Because people are crazy.

Comment one: actually I think you're wrong about that.
In the usage here "modern" is usually relative to the
time of the utterance; hence we have expressions like
"then-modern" or "modern for its day".

Comment two: it's humor. Just enjoy the joke.

 

[Seebs]

Comment one: actually I think you're wrong about that.
In the usage here "modern" is usually relative to the
time of the utterance; hence we have expressions like
"then-modern" or "modern for its day".

In most fields. However, I think there's now at least one field in
which the current time is "post modern" and "modern" is some years ago.

Comment two: it's humor. Just enjoy the joke.

The way I enjoy a funny quibble is by posting even more quibbles. It's
fun for *me*, anyway.

-s

 

[Ian Collins]

Comment one: actually I think you're wrong about that.
In the usage here "modern" is usually relative to the
time of the utterance; hence we have expressions like
"then-modern" or "modern for its day".

"Modern Art".

Comment two: it's humor. Just enjoy the joke.

Modern Art

 

[Eric Sosman]

Comment one: actually I think you're wrong about that.
In the usage here "modern" is usually relative to the
time of the utterance; hence we have expressions like
"then-modern" or "modern for its day".

Comment two: it's humor. Just enjoy the joke.

Right. Post-modernism is *so* last millennium.

 

[Tim Rentsch]

The way I enjoy a funny quibble is by posting even more quibbles.

That's cool, except my response wasn't a quibble, it was
just a joke.

 

[Michael Press]

No, just linguistics. Actually, there are fields in which it would be
perfectly ordinary for a modern thing to have happened 25 years ago,
and fairly shocking for it to have happened this year, because "modern"
got attached to an absolute period rather than remaining a general term
for "the current time frame". Why? Because people are crazy.

Here is an entry from an 1828 dictionary:

MOD''ERN, a. [L. modo, and ern, which we find in other
Latin words that have reference to time, as in hodiernus, hesternus.]

1. Pertaining to the present time, or time not long past;
late; recent; not ancient or remote in past time;
as modern days, ages or time; modern authors;
modern fashions; modern taste; modern practice.