Register variables doubt

[Vashna]

Hi Group,

I have a doubt about register variables.

I know that if we have a variable used very frequently in a function,
then provided we never apply the & function to it, we can define it as a
register variable and this will make it much faster to access.

Now the question is: obviously there are only a fixed number of
registers in our CPU, maybe 6 or something. So how do we choose which
variables to define as register variables? Obviously things like loop
counters or frequently accessed pointers we must define as register, but
what other criteria do people use?

Thanks.

[Mark Bluemel]

Vashna wrote:

Hi Group,

I have a doubt about register variables.

I know that if we have a variable used very frequently in a function,
then provided we never apply the & function to it, we can define it as a
register variable and this will make it much faster to access.

Now the question is: obviously there are only a fixed number of
registers in our CPU, maybe 6 or something. So how do we choose which
variables to define as register variables? Obviously things like loop
counters or frequently accessed pointers we must define as register, but
what other criteria do people use?

http://www.c-faq.com is the Frequently Asked Questions database for this
newsgroup.

You probably need to start with Question 20.13

[santosh]

Vashna wrote:

Hi Group,

I have a doubt about register variables.

I know that if we have a variable used very frequently in a function,
then provided we never apply the & function to it, we can define it as a
register variable and this will make it much faster to access.

Furthermore external objects are not permitted to be qualified with
register.

Also stating with certainty that an object qualified with register will be
accessed "much faster" is not correct. The compiler is free to ignore the
qualifier.

Now the question is: obviously there are only a fixed number of
registers in our CPU, maybe 6 or something. So how do we choose which
variables to define as register variables? Obviously things like loop
counters or frequently accessed pointers we must define as register, but
what other criteria do people use?

With most modern compilers programmers do not use the register qualifier at
all. The reason is that the compiler's optimiser is likely to almost always
to better register allocation than the programmer.

[Gordon Burditt]

>I have a doubt about register variables.

>
I know that if we have a variable used very frequently in a function,
then provided we never apply the & function to it, we can define it as a
register variable and this will make it much faster to access.

You should not know that it will make it faster, that it will make
it much faster, nor that it will make it slower or much slower.
But it might. The compiler is free to ignore the register declaration
entirely.

>Now the question is: obviously there are only a fixed number of
registers in our CPU, maybe 6 or something. So how do we choose which
variables to define as register variables?

I generally let the compiler do its job and define none. Dedicating
a register might slow down other calculations that need it more.

>Obviously things like loop
counters or frequently accessed pointers we must define as register, but
what other criteria do people use?

If you have MEASURED the performance both ways, and register improves
performance, go ahead and use it, but be prepared to MEASURE again when
moving to a different platform / compiler / OS.

[Philip Potter]

Vashna wrote:

Hi Group,

I have a doubt about register variables.

I know that if we have a variable used very frequently in a function,
then provided we never apply the & function to it, we can define it as a
register variable and this will make it much faster to access.

Now the question is: obviously there are only a fixed number of
registers in our CPU, maybe 6 or something. So how do we choose which
variables to define as register variables? Obviously things like loop
counters or frequently accessed pointers we must define as register, but
what other criteria do people use?

As others have said, register is freely ignored by the compiler, and the
compiler almost always does a better job of register allocation than the
programmer. If a variable would be better stored in a register, the
compiler will work that out for you and put it there.

Just don't use the 'register' keyword. Like 'auto', there is no need for
it. (Unlike 'auto', it is conceivable that in some old compilers there
was a need for 'register'.)

--
Philip Potter pgp <atdoc.ic.ac.uk

[pete]

Vashna wrote:

>
Hi Group,

I have a doubt about register variables.

I know that if we have a variable used very frequently in a function,
then provided we never apply the & function to it,
we can define it as a
register variable and this will make it much faster to access.

Now the question is: obviously there are only a fixed number of
registers in our CPU, maybe 6 or something. So how do we choose which
variables to define as register variables?

We can only choose which variables to define as register variables
for specific C implementations.

Obviously things like loop
counters or frequently accessed pointers we must define as register,

No.
The register keyword is *not* something that can be used
to good effect for a program which is intended
to run on arbitrary C implementations.

but what other criteria do people use?

The register keyword tells the compiler
that the code writer thinks that he knows
more about optimization than the compiler does.

Use the register keyword when you know more
about optimization than your compiler does;
and get ready to remove the register keyword from your code
if the code is supposed to be able to run on other C implementations.

--
pete

[CBFalconer]

pete wrote:

Vashna wrote:

>I have a doubt about register variables.

I know that if we have a variable used very frequently in a
function, then provided we never apply the & function to it,
we can define it as a
register variable and this will make it much faster to access.

Now the question is: obviously there are only a fixed number of
registers in our CPU, maybe 6 or something. So how do we choose
which variables to define as register variables?

We can only choose which variables to define as register
variables for specific C implementations.

>Obviously things like loop counters or frequently accessed
pointers we must define as register,

No. The register keyword is *not* something that can be used
to good effect for a program which is intended to run on
arbitrary C implementations.

>but what other criteria do people use?

The register keyword tells the compiler
that the code writer thinks that he knows
more about optimization than the compiler does.

Use the register keyword when you know more
about optimization than your compiler does;
and get ready to remove the register keyword from your code
if the code is supposed to be able to run on other C implementations.

You have it all wrong. The register keyword may always be ignored
by the compiler, with the sole exception that it makes taking the
address of the object impossible. This allows the compiler to
completely control the optimization. So using it (register) is
pointless, except on some ancient compilers that can't do
optimization at all.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

pete wrote:

[...]

>The register keyword tells the compiler
that the code writer thinks that he knows
more about optimization than the compiler does.

Use the register keyword when you know more
about optimization than your compiler does;
and get ready to remove the register keyword from your code
if the code is supposed to be able to run on other C implementations.

You have it all wrong. The register keyword may always be ignored
by the compiler, with the sole exception that it makes taking the
address of the object impossible. This allows the compiler to
completely control the optimization. So using it (register) is
pointless, except on some ancient compilers that can't do
optimization at all.

That's the common widom, but I wonder how accurate it is.

First, here's what the standard says (C99 6.7.1p4):

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.

with a footnote:

The implementation may treat any register declaration simply as an
auto declaration. However, whether or not addressable storage is
actually used, the address of any part of an object declared with
storage-class specifier register cannot be computed, either
explicitly (by use of the unary & operator as discussed in
6.5.3.2) or implicitly (by converting an array name to a pointer
as discussed in 6.3.2.1). Thus, the only operator that can be
applied to an array declared with storage-class specifier register
is sizeof.

Do modern compilers really ignore the "register" keyword (except to
prohibit taking the address of the object)? Or do some of them pay
some attention to it, at least in some modes?

It seems at least plausible that, if I've carefully profiled my code
and found that references to a particular int object are a bottleneck,
declaring it "register" at least is unlikely to hurt.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Vashna]

Thanks for all the answers, I feel like I understand it much better now.

The only doubt I still have is: what if in a single function we define
more register variables than there are registers in the CPU? Will we get
a compile time error, or just unpredictable behavior at runtime?

(Actually I guess you may not even be able to have one register variable
for each register, if the return value of the function is passed back to
the caller in a register.)

Thanks.

[santosh]

Vashna wrote:

Thanks for all the answers, I feel like I understand it much better now.

The only doubt I still have is: what if in a single function we define
more register variables than there are registers in the CPU? Will we get
a compile time error, or just unpredictable behavior at runtime?

Neither. The implementation will simply ignore one or more or all of your
register requests.

<snip>

[Richard]

santosh <sa*********@gmail.comwrites:

Vashna wrote:

>Thanks for all the answers, I feel like I understand it much better now.

The only doubt I still have is: what if in a single function we define
more register variables than there are registers in the CPU? Will we get
a compile time error, or just unpredictable behavior at runtime?

Neither. The implementation will simply ignore one or more or all of your
register requests.

This is unpredictable behaviour. Personally I think its a failing in
such a low level language not to be able to ensure register assignment
within the constraints of the HW.

>
<snip>

[santosh]

Richard wrote:

santosh <sa*********@gmail.comwrites:

>Vashna wrote:

>>Thanks for all the answers, I feel like I understand it much better
now.

The only doubt I still have is: what if in a single function we
define more register variables than there are registers in the CPU?
Will we get a compile time error, or just unpredictable behavior at
runtime?

Neither. The implementation will simply ignore one or more or all of
your register requests.

This is unpredictable behaviour.

No it's not since the Standard explicitly excuses a conforming
implementation from guaranteeing anything with regard to the register
specifier other than disallowing taking their address.

Personally I think its a failing in
such a low level language not to be able to ensure register assignment
within the constraints of the HW.

Since C is meant to be implemented on a great variety of hardware from
those having no more than two or three to those with hundreds of
registers, how would you propose to ensure register assignment for
register qualified objects.

Register assignment is already done as a part of translation, the
register specifier is merely a "hint" from the programmer to help the
compiler's register allocator and optimiser.

Forcing implementations to honour the register specifier, even within
the constraints of the hardware, is likely to lead to worse code than
letting the compiler do the job. The compiler almost always has more
knowledge of the target architecture than an average programmer. There
is always the option of inline assembler or separately assembler
routines when an experienced programmer needs to extract specific use
of the hardware.

[Keith Thompson]

Richard <rg****@gmail.comwrites:

santosh <sa*********@gmail.comwrites:

>Richard wrote:

>>santosh <sa*********@gmail.comwrites:
Vashna wrote:

[...]

>>>>The only doubt I still have is: what if in a single function we
define more register variables than there are registers in the CPU?
Will we get a compile time error, or just unpredictable behavior at
runtime?

Neither. The implementation will simply ignore one or more or all of
your register requests.

This is unpredictable behaviour.

No, it's not behavior at all. The standard defines "behavior" as
"external appearance or action". Register assignment is not behavior
unless it affects the external appearance or action of the program.

[...]

I don't care what the standard says.

If you don't care what the standard says, then I don't care what you
have to say about the language.

If you want assembly language, you know where to find it.

Adding finer-grained register control to C would be a terrible
mistake.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

santosh <sa*********@gmail.comwrites:
[...]

Personally I'd prefer the Standardisation of the asm keyword and
associated semantics, as has been done with C++, than further messing
around with register.

C++ defines the asm keyword and its syntax:

asm ( string-literal ) ;

but leaves its semantics entirely implementation-defined.

I'm not convinced that this is useful. Any program that uses ``asm''
is inherently non-portable, and must be modified if it's to be ported
to another platform. I don't see how standardizing part of the syntax
aids portability (or anything else).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[santosh]

Richard wrote:

santosh <sa*********@gmail.comwrites:

>Richard wrote:

>>santosh <sa*********@gmail.comwrites:

<snip>

>>>No it's not since the Standard explicitly excuses a conforming
implementation from guaranteeing anything with regard to the
register specifier other than disallowing taking their address.

I don't care what the standard says. It is unpredictable behaviour.
Not "undefined". It is unpredictable since you have NO idea if or
how a register is assigned. You correctly point out however, that
one CAN go to assembler if the glove really doesn't fit.

<snip>

>probably need careful modification when porting from one architecture
to another or even from one implementation to another. Also the
disadvantage of not being able to derive the address of the concerned
objects might become onerous.

I'm not sure we are talking about the same thing. You appear to be
talking about how it is, rather than discussing the potential
usefulness of having more concrete register behaviour.

Okay maybe you should propose a syntax for this and cross-post it c.s.c
and here? Then we can discuss something concrete.

<snip>

>Personally I'd prefer the Standardisation of the asm keyword and
associated semantics, as has been done with C++, than further messing
around with register.

That is a ridiculous idea. Would you also propose a single ASM
language for all processors?

Not at all. I'm talking about including the 'asm' keyword into Standard
C, not it's actual usage. Right now we have a variety of implementation
defined keywords for inline assembler like 'asm' '_asm' '__asm__' if
the facility exists at all.

[Vashna]

But then that raises even more questions! Suppose I define register
variables a,b,c,d,e and the CPU has only 4 registers. In this case, if
what you say is true, the compiler will put one of these variables into
a memory location. This means we can take the address of it with the &
function. So is it the last defined variable that will be put into
memory? And if so, if we compile the program on a machine with 6
registers and we've relied on using &e somewhere, this will lead to a
runtime error...

This seems like a worrying ambiguous point in the language!

Thanks.

On 6 Oct 2007 at 14:30, santosh wrote:

Vashna wrote:

>Thanks for all the answers, I feel like I understand it much better now.

The only doubt I still have is: what if in a single function we define
more register variables than there are registers in the CPU? Will we get
a compile time error, or just unpredictable behavior at runtime?

Neither. The implementation will simply ignore one or more or all of your
register requests.

<snip>

[santosh]

Vashna wrote:
[please don't top post; fixed here]

On 6 Oct 2007 at 14:30, santosh wrote:

>Vashna wrote:

>>Thanks for all the answers, I feel like I understand it much better
now.

The only doubt I still have is: what if in a single function we
define more register variables than there are registers in the CPU?
Will we get a compile time error, or just unpredictable behavior at
runtime?

Neither. The implementation will simply ignore one or more or all of
your register requests.

But then that raises even more questions! Suppose I define register
variables a,b,c,d,e and the CPU has only 4 registers. In this case, if
what you say is true, the compiler will put one of these variables
into a memory location.

Don't assume that it'll put only _one_ of 'a', 'b', 'c' or 'd' into
memory. It could be anywhere between one to all of them. You cannot
determine portabily which.

This means we can take the address of it with
the & function.

No. The address of _all_ objects qualified with register cannot be
taken. This follows from the rule that register is merely a hint and
may or may not be actually honoured. Since it's impossible for a
Standard C program to determine which of it's register qualified
objects have *actually* been placed into registers, the Standard
prohibits all of them from having an address.

So is it the last defined variable that will be put
into memory? And if so, if we compile the program on a machine with 6
registers and we've relied on using &e somewhere, this will lead to a
runtime error...

This seems like a worrying ambiguous point in the language!

No. All objects qualified with register do not have addresses.

[Keith Thompson]

santosh <sa*********@gmail.comwrites:

Vashna wrote:

[...]

>But then that raises even more questions! Suppose I define register
variables a,b,c,d,e and the CPU has only 4 registers. In this case, if
what you say is true, the compiler will put one of these variables
into a memory location.

Don't assume that it'll put only _one_ of 'a', 'b', 'c' or 'd' into
memory. It could be anywhere between one to all of them. You cannot
determine portabily which.

>This means we can take the address of it with
the & function.

No. The address of _all_ objects qualified with register cannot be
taken. This follows from the rule that register is merely a hint and
may or may not be actually honoured. Since it's impossible for a
Standard C program to determine which of it's register qualified
objects have *actually* been placed into registers, the Standard
prohibits all of them from having an address.

Actually, it follows from the explicit statement in the standard that
the unary "&" shall not be applied to an object declared with the
register storage-class specifier (C99 6.5.3.2p1).

>So is it the last defined variable that will be put
into memory? And if so, if we compile the program on a machine with 6
registers and we've relied on using &e somewhere, this will lead to a
runtime error...

This seems like a worrying ambiguous point in the language!

No. All objects qualified with register do not have addresses.

That last sentence is ambiguous; what you mean, I think, is that no
objects qualfied with register have addresses. (It could also be read
as "Not all objects qualified with register have addresses", which
leaves open the possibility that some of them do.)

But the actual rule is that a register-qualified object's address
cannot be computed. It might have an address; you just can't get it.
(On the other hand, as far as the visible semantics are concerned, it
really doesn't have an address.)

And an object without register qualification might still be stored in
a CPU register, and not have an address. Even if the program applies
"&" to it, the compiler just has to guarantee that it exists at that
address when it's used. For example:

int x = 42;
printf("Address of x is %p\n", (void*)&x);
/*
* Followed by a bunch of code that refers to the value of x, but
* not to its address.
*/

The compiler might decide to store x in a register after the printf
statement.

The "register" keyword does just two things.

1. It hints to the compiler that accesses to the object should be fast
(and maybe putting it in a register is a good way to do that).

2. It forbids taking the address of the object.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Vashna]

On 6 Oct 2007 at 19:47, santosh wrote:

Vashna wrote:
[please don't top post; fixed here]

>On 6 Oct 2007 at 14:30, santosh wrote:

>>Vashna wrote:

Thanks for all the answers, I feel like I understand it much better
now.

The only doubt I still have is: what if in a single function we
define more register variables than there are registers in the CPU?
Will we get a compile time error, or just unpredictable behavior at
runtime?

Neither. The implementation will simply ignore one or more or all of
your register requests.

But then that raises even more questions! Suppose I define register
variables a,b,c,d,e and the CPU has only 4 registers. In this case, if
what you say is true, the compiler will put one of these variables
into a memory location.

Don't assume that it'll put only _one_ of 'a', 'b', 'c' or 'd' into
memory. It could be anywhere between one to all of them. You cannot
determine portabily which.

>This means we can take the address of it with
the & function.

No. The address of _all_ objects qualified with register cannot be
taken. This follows from the rule that register is merely a hint and
may or may not be actually honoured. Since it's impossible for a
Standard C program to determine which of it's register qualified
objects have *actually* been placed into registers, the Standard
prohibits all of them from having an address.

Are you reaaly sure that's right? What about C programs used in
device drivers or lowlevel kernel work that really need to know when a
variable is going to be stored in a register?

[santosh]

Vashna wrote:

On 6 Oct 2007 at 19:47, santosh wrote:

>Vashna wrote:
[please don't top post; fixed here]

>>On 6 Oct 2007 at 14:30, santosh wrote:
Vashna wrote:

Thanks for all the answers, I feel like I understand it much
better now.
>
The only doubt I still have is: what if in a single function we
define more register variables than there are registers in the
CPU? Will we get a compile time error, or just unpredictable
behavior at runtime?

Neither. The implementation will simply ignore one or more or all
of your register requests.

But then that raises even more questions! Suppose I define register
variables a,b,c,d,e and the CPU has only 4 registers. In this case,
if what you say is true, the compiler will put one of these
variables into a memory location.

Don't assume that it'll put only _one_ of 'a', 'b', 'c' or 'd' into
memory. It could be anywhere between one to all of them. You cannot
determine portabily which.

>>This means we can take the address of it with
the & function.

No. The address of _all_ objects qualified with register cannot be
taken. This follows from the rule that register is merely a hint and
may or may not be actually honoured. Since it's impossible for a
Standard C program to determine which of it's register qualified
objects have *actually* been placed into registers, the Standard
prohibits all of them from having an address.

Are you reaaly sure that's right?

Yes.

What about C programs used in device drivers or lowlevel kernel work
that really need to know when a variable is going to be stored in a
register?

Even in most cases of system programming it's not necessary to know
which objects are currently in registers. The whole purpose of a
high-level language like C is to free the programmer of such a burden.

When a register _must_ be used the only options are to drop down to
assembler or inline assembler, if the latter is supported by the
implementation.

[CBFalconer]

santosh wrote:

>

.... snip ...

>
Personally I'd prefer the Standardisation of the asm keyword and
associated semantics, as has been done with C++, than further
messing around with register.

Rather hard unless you simultaneously restrict C to run on only one
architecture. :-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

CBFalconer wrote:

santosh wrote:
.... snip ...

>Personally I'd prefer the Standardisation of the asm keyword and
associated semantics, as has been done with C++, than further
messing around with register.

Rather hard unless you simultaneously restrict C to run on only one
architecture. :-)

The C++ standard for the asm declaration is simply

asm ( string-literal ) ;

The meaning is implementation defined.

The informative annex J.5.10 in C99 says pretty much the same.

--
Ian Collins.

[Chris Torek]

>santosh <sa*********@gmail.comwrites:

>Personally I'd prefer the Standardisation of the asm keyword and
associated semantics, as has been done with C++, than further messing
around with register.

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>C++ defines the asm keyword and its syntax:

asm ( string-literal ) ;

but leaves its semantics entirely implementation-defined.

I'm not convinced that this is useful. ...

It seems to me to be as useful as the non-Standard-ized pragmas.

>Any program that uses ``asm'' is inherently non-portable, and must
be modified if it's to be ported to another platform. I don't see
how standardizing part of the syntax aids portability (or anything else).

It mostly avoids getting dozens of incompatible syntaxes for
"common extensions". The situation today in C is that we have
things like:

#ifdef USING_GCC
__asm__("xyz %1,%0" : "=r"(result) : "r"(input));
#endif
#ifdef USING_FOO_C
_Asm {
xyz $t0,$r3
}
#endif
#ifdef USING_BAR_C
asm xyz r3,t0
#endif
/* ... */

If they all had reasonably-compatible syntax, we might at least have:

#ifdef USING_GCC
# define INSTRUCTION "xyz %1, %0" : "=r"(result) : "r"(input)
#endif
#ifdef USING_FOO_C
# define INSTRUCTION "xyz $t0,$r3"
#endif
#ifdef USING_BAR_C
# define INSTRUCTION "xyz r3,t0"
#endif
#ifndef INSTRUCTION
# error do not know how to do inline assembly with this compiler
#endif
asm(INSTRUCTION);

which seems to be a *slight* improvement, anyway.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Eric Sosman]

Richard wrote:

>
I don't care what the standard says. It is unpredictable behaviour. Not
"undefined". It is unpredictable since you have NO idea if or how a
register is assigned. [...]

I'm not sure, but are you asking for the compiler to
emit an error message if it doesn't honor your `register'
keyword?

(And then there's the slippery question of just what
it means to "honor" the keyword ...)

--
Eric Sosman
es*****@ieee-dot-org.invalid

[CBFalconer]

Chris Torek wrote:

>

.... snip ...

>
If they all had reasonably-compatible syntax, we might at least have:

#ifdef USING_GCC
# define INSTRUCTION "xyz %1, %0" : "=r"(result) : "r"(input)
#endif
#ifdef USING_FOO_C
# define INSTRUCTION "xyz $t0,$r3"
#endif
#ifdef USING_BAR_C
# define INSTRUCTION "xyz r3,t0"
#endif
#ifndef INSTRUCTION
# error do not know how to do inline assembly with this compiler
#endif
asm(INSTRUCTION);

which seems to be a *slight* improvement, anyway.

Seems to me it would be easier to write appropriate source files
for each system, and simply arrange for the make file to
assemble/compile the appropriate one. After that the linker can
take care of things.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Kenneth Brody]

Richard wrote:

>
santosh <sa*********@gmail.comwrites:

Richard wrote:

santosh <sa*********@gmail.comwrites:

[...]

>Neither. The implementation will simply ignore one or more or all of
your register requests.

This is unpredictable behaviour.

No it's not since the Standard explicitly excuses a conforming
implementation from guaranteeing anything with regard to the register
specifier other than disallowing taking their address.

I don't care what the standard says. It is unpredictable behaviour. Not
"undefined". It is unpredictable since you have NO idea if or how a
register is assigned. You correctly point out however, that one CAN go
to assembler if the glove really doesn't fit.

[...]

I'm not sure I agree with you on this one. If the compiler did its
job, there will be no discernable difference in behavior whether the
variable is placed in a register or not, aside from a possible change
in speed of execution. (And, just to be clear, if the compiler were
forced to heed your "demand" that the variable be placed in a register,
that version might actually run slower than if the compiler were
allowed to pick which variables went in registers.)

If there is no discernable difference in behavior, where exactly does
this "unpredictable" part come into play?

And, if not placing a register variable into a register causes
"unpredictable" behavior, can't the same be said about placing a
non-register variable into a register?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[David Thompson]

On Sat, 06 Oct 2007 12:17:12 -0700, Keith Thompson <ks***@mib.org>
wrote:

santosh <sa*********@gmail.comwrites:
[...]

Personally I'd prefer the Standardisation of the asm keyword and
associated semantics, as has been done with C++, than further messing
around with register.

C++ defines the asm keyword and its syntax:

asm ( string-literal ) ;

but leaves its semantics entirely implementation-defined.

I'm not convinced that this is useful. Any program that uses ``asm''
is inherently non-portable, and must be modified if it's to be ported
to another platform. I don't see how standardizing part of the syntax
aids portability (or anything else).

It allows other tools to correctly parse (the C part of) the code
without needing to know the asm quirks for particular compiler(s).

- formerly david.thompson1 || achar(64) || worldnet.att.net