Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3830 > unrolled thread

Register storage type

Back to article view | Back to comp.lang.c

Contents

  Register storage type Free Willy <nospam@nospam.com> - 2011-05-12 20:55 +0000
    Re: Register storage type Kenneth Brody <kenbrody@spamcop.net> - 2011-05-12 17:02 -0400
      Re: Register storage type Free Willy <nospam@nospam.com> - 2011-05-12 21:13 +0000
        Re: Register storage type Angel <angel+news@spamcop.net> - 2011-05-12 21:20 +0000
        Re: Register storage type Keith Thompson <kst-u@mib.org> - 2011-05-12 14:27 -0700
          Re: Register storage type Kenneth Brody <kenbrody@spamcop.net> - 2011-05-13 13:20 -0400
            Re: Register storage type Free Willy <nospam@nospam.com> - 2011-05-13 21:30 +0000
              Re: Register storage type Keith Thompson <kst-u@mib.org> - 2011-05-13 15:50 -0700
                Different languages (Was: Register storage type) gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-14 08:58 +0000
                  Re: Different languages (Was: Register storage type) Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-14 10:09 +0100
                Re: Register storage type Free Willy <nospam@nospam.com> - 2011-05-14 21:27 +0000
                  Re: Register storage type Ian Collins <ian-news@hotmail.com> - 2011-05-15 09:55 +1200
                  Re: Register storage type Keith Thompson <kst-u@mib.org> - 2011-05-14 16:46 -0700
                    Re: Register storage type Jens <jens.gustedt@gmail.com> - 2011-05-15 10:08 -0700
                      Re: Register storage type James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:09 -0400
                    Re: Register storage type David Thompson <dave.thompson2@verizon.net> - 2011-05-19 01:50 -0400
                  Re: Register storage type Stephen Sprunk <stephen@sprunk.org> - 2011-05-15 00:27 -0500
                  Re: Register storage type Angel <angel+news@spamcop.net> - 2011-05-15 12:56 +0000
                    Re: Register storage type Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-15 11:54 -0400
                      Re: Register storage type Seebs <usenet-nospam@seebs.net> - 2011-05-15 17:43 +0000
                        Re: Register storage type Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 23:37 -0700
                          Re: Register storage type Seebs <usenet-nospam@seebs.net> - 2011-05-19 14:37 +0000
                            Drift: Linguistics (was Re: Register storage type) Kenneth Brody <kenbrody@spamcop.net> - 2011-05-19 13:17 -0400
                            Re: Register storage type Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 11:05 -0700
                              Re: Register storage type Seebs <usenet-nospam@seebs.net> - 2011-05-19 19:08 +0000
                                Re: Register storage type Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 00:39 -0700
                              Re: Register storage type Ian Collins <ian-news@hotmail.com> - 2011-05-20 07:46 +1200
                              Re: Register storage type Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-19 22:37 -0400
                            Re: Register storage type Michael Press <rubrum@pacbell.net> - 2011-05-25 12:57 -0700
                    Re: Register storage type pete <pfiland@mindspring.com> - 2011-05-15 09:09 -0400
        Re: Register storage type Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-12 21:57 -0400
    Re: Register storage type Angel <angel+news@spamcop.net> - 2011-05-12 21:14 +0000
      Re: Register storage type gordonb.unc3q@burditt.org (Gordon Burditt) - 2011-05-13 07:49 -0500
    Re: Register storage type Keith Thompson <kst-u@mib.org> - 2011-05-12 14:20 -0700
      Re: Register storage type Seebs <usenet-nospam@seebs.net> - 2011-05-12 21:59 +0000
        Re: Register storage type BGB <cr88192@hotmail.com> - 2011-05-12 15:50 -0700
        Re: Register storage type Keith Thompson <kst-u@mib.org> - 2011-05-12 15:49 -0700
          Re: Register storage type Seebs <usenet-nospam@seebs.net> - 2011-05-12 23:19 +0000
            Re: Register storage type Keith Thompson <kst-u@mib.org> - 2011-05-12 16:29 -0700
              Re: Register storage type Seebs <usenet-nospam@seebs.net> - 2011-05-13 00:15 +0000
    Re: Register storage type Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 15:24 -0700
    Re: Register storage type Peter Nilsson <airia@acay.com.au> - 2011-05-12 17:39 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4293

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-05-15, Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>>      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.

[toc] | [prev] | [next] | [standalone]

#4323

On 2011-05-19, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> 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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4340 — Drift: Linguistics (was Re: Register storage type)

On 5/19/2011 10:37 AM, Seebs wrote:
> On 2011-05-19, Tim Rentsch<txr@alumni.caltech.edu>  wrote:
>> 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.

I used modern compilers 25 years ago.  They just weren't as good as today's 
modern compilers.

> 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.  :)

Not to mention the fact that "modern" is also relative, based on the 
context.  I live in a town with many houses that were built in the 1800's, 
so something built in 1970 might be considered a "modern" house.  Yet my 
mother lives in an area that was huge tracts of farmland just 20 years ago 
(and, in fact, still has large "undeveloped" areas of land), so something 
from 1970 would probably be "ancient".

And, if talking about world history, 1900 would still probably be considered 
"modern".  Even the light bulb could be called a "modern" invention.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#4342

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-05-19, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> 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.  :)

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.

[toc] | [prev] | [next] | [standalone]

#4355

On 2011-05-19, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> 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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4677

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-05-19, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Comment two:  it's humor.  Just enjoy the joke.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#4362

On 05/20/11 06:05 AM, Tim Rentsch wrote:
> Seebs<usenet-nospam@seebs.net>  writes:
>
>> On 2011-05-19, Tim Rentsch<txr@alumni.caltech.edu>  wrote:
>>> 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.  :)
>
> 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 :)

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#4410

On 5/19/2011 2:05 PM, Tim Rentsch wrote:
> Seebs<usenet-nospam@seebs.net>  writes:
>
>> On 2011-05-19, Tim Rentsch<txr@alumni.caltech.edu>  wrote:
>>> 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.  :)
>
> 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.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#4777

In article <slrnitaaao.ei7.usenet-nospam@guild.seebs.net>,
 Seebs <usenet-nospam@seebs.net> wrote:

> On 2011-05-19, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> > 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.  :)

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.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#4026

Angel wrote:
 
> 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.

This was aniticipated in the 1978 version of K&R.
Appendix A, 8.1
"Samller, faster programs can be expected 
 if register declarations are used appropriately, 
 but future improvements in code generation
 may render them unnecessary."

-- 
pete

[toc] | [prev] | [next] | [standalone]

#3883

On 5/12/2011 5:13 PM, Free Willy wrote:
> [...]
> Another question is array variables declared as register type - could the
> compiler put a small array say of 3 elements into different registers and
> translate array accesses to the right register?

     It is possible to define an array with `register', but the
array is pretty much useless.  Since all array accesses are defined
in terms of pointer operations, and since you can't form a pointer
to a register variable, you wind up with an array you can't use!
The only operation you can do with it is apply `sizeof'.

     Stepping back a second and taking a wider view, I suspect your
fascination with `register' is unhealthy, and that you should
muster all your will power to forget the keyword's existence.  You
mention a CPU with only a few hardware registers, and (it seems)
you imagine you'll get greater speed by dedicating them to your
most frequently-used variables.  Tell me, then: If all the registers
are busy holding the values of `w', `x', `y', `z', where will the
compiler keep the intermediate results in `x * y + w * z'?

     Drop it.  Just drop it, and step away from the keyboard, keeping
both hands in view.  Good.  Now show me the MEASUREMENTS that indicate
you need to micro-optimize.  If you haven't made them, I'm giving you
a ticket and a fine for Premature Optimization.  Do you feel lucky?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#3835

On 2011-05-12, Free Willy <nospam@nospam.com> wrote:
>
> Say the CPU has only AL, BL, CL, DL or eight 8 bit registers, and if
> want to declare 10 register variables in my code, is it possible to do
> it?

The"register" specifier is a hint for the compiler; the compiler
is not required to follow it. If it's not possible on a given
architecture, then of course the compiler will ignore it and treat the
variable like any other.

> Say size_of(float) is the same as size_of(int), is it possible to define 
> a "register float" variable? How will the register get converted between 
> int and float?

Size or type don't matter, you can give any automatic variable the register
specifier. The compiler will assign an actual register if it is feasible
to do so. This varies per implementation.

Internally, any type of variable is represented as a number of bits,
which is the only thing a computer can work with. If the number of bits
required to represent the variable can fit in a register, the compiler
may do so. No special conversion is needed; a variable in a register is no
different from a variable in normal memory, except that you cannot have a
pointer to a register.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#3902

> Size or type don't matter, you can give any automatic variable the register
> specifier. The compiler will assign an actual register if it is feasible
> to do so. This varies per implementation.

I think I ran into a compiler that had the characteristics that if
you gave a few register declarations (carefully thinking about which
variables were most referenced and most referenced in inner loops),
you could improve the code, sometimes significantly, but if you
gave *everything* a register declaration far beyond the availability
of hardware registers, you'd probably end up with code slightly
worse than no register declarations (it has to generate code to
load the registers, especially if these are function parameters).
Compiler technology has improved a lot since then.  But if you're
going to use "register", use it as a hint that accesses to THIS
variable are better optimized than accesses to THAT one, which
means using it on only a few variables in each function.  That
might require knowing that this variable is used in the main loop,
as opposed to that one which is used in hopefully-never-executed
error handling.
 
> Internally, any type of variable is represented as a number of bits,
> which is the only thing a computer can work with. If the number of bits
> required to represent the variable can fit in a register, the compiler
> may do so. 

Or it may not.  If the computer has only specific-purpose registers
(e.g. some for float and some for integers/pointers/characters),
or perhaps has a couple of general-purpose registers which it has
already used along with the specific-purpose registers, it may not
be possible to stick an arbitrary integer into a floating-point
register of the same size: if it bit-copies, it risks the integer
having a trap representation in floating point (in this case, it
should refuse to put integers in floating-point registers).  If it
converts, it will lose accuracy (here also it should refuse to put
integers in floating-point registers of the same size).  Think about
computers in an architecture (e.g. x86) where the "floating point
unit" is somewhat a separate entity and it used to be optional.

It may also be impractical (and a pessimization) to store an integer
in a floating-point register, even if you avoid trapping and
conversions, as it may have to go through memory to get it to an
integer register where you can do integer math with it, which might
be slower than just putting it in memory in the first place.

There are also computers where the registers are separated for
pointers and integers, although you can move data between them,
using it for its intended purpose quickly may require it to go into
a register of the right type (e.g. Motorola 680XX).

> No special conversion is needed; a variable in a register is no
> different from a variable in normal memory,

Except that a variable in the wrong type of register may be slower
than a variable in normal memory.

> except that you cannot have a
> pointer to a register.

[toc] | [prev] | [next] | [standalone]

#3838

Free Willy <nospam@nospam.com> writes:
> Say the CPU has only AL, BL, CL, DL or eight 8 bit registers, and if
> want to declare 10 register variables in my code, is it possible to do
> it?

Certainly, you can declare as many register variables as you like.

> Say size_of(float) is the same as size_of(int), is it possible to define 
> a "register float" variable? How will the register get converted between 
> int and float?

(It's "sizeof", not "size_of".)

You can define a "register float" variable regardless of the relative
sizes of int and float.  No conversion is implied.  You can use the
"register" specifier for any declaration, as long as it's inside a
function (though declaring an array as "register" means you can't
do anything with it other than applying "sizeof").

The thing to remember is that "register" doesn't mean "store this
object in a CPU register".  All the standard says is that

    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 isimplementation-defined.

and that you can't take the address of a register object, or declare
one outside a function.

The common wisdom these days is that the compiler can do a better
job of deciding what to store in a register than you're likely to,
and that declaring objects as "register" can even hurt performance
if the compiler pays attention to it.  I'm actually not sure whether
this is correct in general.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#3844

On 2011-05-12, Keith Thompson <kst-u@mib.org> wrote:
> The common wisdom these days is that the compiler can do a better
> job of deciding what to store in a register than you're likely to,
> and that declaring objects as "register" can even hurt performance
> if the compiler pays attention to it.  I'm actually not sure whether
> this is correct in general.

It can have one positive effect:

Because it guarantees that the address of a thing can't be taken, it can
in some cases allow a compiler to optimize better whether or not it puts
the object in question "in a register", just because there's no need to worry
about things modifying the object through pointers.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#3852

On 5/12/2011 2:59 PM, Seebs wrote:
> On 2011-05-12, Keith Thompson<kst-u@mib.org>  wrote:
>> The common wisdom these days is that the compiler can do a better
>> job of deciding what to store in a register than you're likely to,
>> and that declaring objects as "register" can even hurt performance
>> if the compiler pays attention to it.  I'm actually not sure whether
>> this is correct in general.
>
> It can have one positive effect:
>
> Because it guarantees that the address of a thing can't be taken, it can
> in some cases allow a compiler to optimize better whether or not it puts
> the object in question "in a register", just because there's no need to worry
> about things modifying the object through pointers.
>

yes, but a compiler can easily enough infer that the address isn't taken.

for example:
void func()
{
	int x;
	...
}

if the compiler doesn't ever see an "&x" or similar in the function, 
then it can generally assume that the address of 'x' is not taken.


well, except maybe if the compiler is single-pass or lacks any sort of 
optimizing stages...


it is much like, there are optimizations that can be broken by the 
ability to freely 'goto' here and there, but an absence of any labels or 
gotos in the area can make these optimizations safe.

say:
if(0) { ... }

an absence of labels/gotos will then allow the compiler to simply omit 
the code indicated by "...".

or such...

[toc] | [prev] | [next] | [standalone]

#3854

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-12, Keith Thompson <kst-u@mib.org> wrote:
>> The common wisdom these days is that the compiler can do a better
>> job of deciding what to store in a register than you're likely to,
>> and that declaring objects as "register" can even hurt performance
>> if the compiler pays attention to it.  I'm actually not sure whether
>> this is correct in general.
>
> It can have one positive effect:
>
> Because it guarantees that the address of a thing can't be taken, it can
> in some cases allow a compiler to optimize better whether or not it puts
> the object in question "in a register", just because there's no need to worry
> about things modifying the object through pointers.

Ah, but "register" can be applied only to block-scope.  Presumably
any decent optimizing compiler can already tell that a block-scope
variable's address is never taken, just by analyzing the code.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#3862

On 2011-05-12, Keith Thompson <kst-u@mib.org> wrote:
> Ah, but "register" can be applied only to block-scope.  Presumably
> any decent optimizing compiler can already tell that a block-scope
> variable's address is never taken, just by analyzing the code.

I try not to make assumptions about whether things are "decent".  The
world continues to surprise and astound me, even after all these years.

Remember:  The phrase "no one would be dumb enough to..." does not come
at the beginning of any true statement.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#3871

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-12, Keith Thompson <kst-u@mib.org> wrote:
>> Ah, but "register" can be applied only to block-scope.  Presumably
>> any decent optimizing compiler can already tell that a block-scope
>> variable's address is never taken, just by analyzing the code.
>
> I try not to make assumptions about whether things are "decent".  The
> world continues to surprise and astound me, even after all these years.
>
> Remember:  The phrase "no one would be dumb enough to..." does not come
> at the beginning of any true statement.

Ok, but your point (that "register" can help an optimizer by telling
it that an object's address is never taken) is relevant only for a
compiler that (a) is too dumb to detect by itself that a block-scope
object's address is never taken, but (b) is smart enough to make
good use of the information.

Conceivable, but not the way I'd bet -- and I wouldn't clutter my
code with otherwise superfluous "register" specifiers to cater to
such compilers without a very good reason.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#3877

On 2011-05-12, Keith Thompson <kst-u@mib.org> wrote:
> Ok, but your point (that "register" can help an optimizer by telling
> it that an object's address is never taken) is relevant only for a
> compiler that (a) is too dumb to detect by itself that a block-scope
> object's address is never taken, but (b) is smart enough to make
> good use of the information.
>
> Conceivable, but not the way I'd bet -- and I wouldn't clutter my
> code with otherwise superfluous "register" specifiers to cater to
> such compilers without a very good reason.

Yeah.  The most significant effect, I think, is probably that if you
have a large code base in which there are multiple actors and some macros
and inline functions, tagging something "register" could prevent someone
from *accidentally* taking its address.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web