Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Register variables doubt

Reply
Thread Tools

Register variables doubt

 
 
Vashna
Guest
Posts: n/a
 
      10-06-2007
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>
>

 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      10-06-2007
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.


 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      10-06-2007
santosh <(E-Mail Removed)> writes:
> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Vashna
Guest
Posts: n/a
 
      10-06-2007
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?

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      10-06-2007
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.

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-06-2007
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.
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      10-07-2007
>santosh <(E-Mail Removed)> writes:
>> 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 <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>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 (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      10-07-2007
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

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      10-07-2007
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
(E-Mail Removed)lid
 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      10-09-2007
Richard wrote:
>
> santosh <(E-Mail Removed)> writes:
>
> > Richard wrote:
> >
> >> santosh <(E-Mail Removed)> writes:

[...]
> >>> 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: <(E-Mail Removed)>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
dotnet doubt can any body clarify my doubt challa462@gmail.com ASP .Net 0 08-22-2012 06:02 AM
Put variables into member variables or function variables? tjumail@gmail.com C++ 9 03-23-2008 04:03 PM
Doubt on Stack variables. deepak C Programming 13 01-16-2007 06:28 AM
doubt about doubt Bob Nelson C Programming 11 07-30-2006 08:17 PM
A doubt about m//'s related variables Michele Dondi Perl Misc 3 07-09-2004 04:46 PM



Advertisments