Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Register variables doubt

 
 
santosh
Guest
Posts: n/a
 
      10-06-2007
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
 
 
 
 
Richard
Guest
Posts: n/a
 
      10-06-2007
santosh <(E-Mail Removed)> writes:

> 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>

 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      10-06-2007
Richard wrote:

> santosh <(E-Mail Removed)> writes:
>
>> 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.

 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      10-06-2007
santosh <(E-Mail Removed)> writes:

> Richard wrote:
>
>> santosh <(E-Mail Removed)> writes:
>>
>>> 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.


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.

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


I am not talking about the standard. But I would document a procedure
which implementations should follow in the standard where the registers
can be queried and assigned and forced if necessary.

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


Yes, We know what it is. That is why I thought I would mention what I
think it should be rather than what it is.

>
> 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


There are times when there is a damn good reason for overriding
this default compiler behaviour.

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


Very true.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      10-06-2007
Richard wrote:

> santosh <(E-Mail Removed)> writes:
>
>> Richard wrote:
>>
>>> santosh <(E-Mail Removed)> writes:
>>>
>>>> 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.

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


Though it's virtually non-existent today, it's always possible that
memory-to-memory processors could make a comeback. Also under RISC CPUs
like the Itanium it will become _very_ tedious and error prone for the
programmer to keep track of register allocation.

Also keep in mind that a source which makes use of your proposal will
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.

In summary I think, (though I may very likely be wrong), that an effort
for Standardising further constraints for register is likely to be
complex and ambiguous. Further I don't think there is enough demand in
the C programming community for this to justify the demand on
implementors and potential loss in portability.

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

>
> I am not talking about the standard. But I would document a procedure
> which implementations should follow in the standard where the
> registers can be queried and assigned and forced if necessary.


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.

<snip>

 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      10-06-2007
santosh <(E-Mail Removed)> writes:

> Richard wrote:
>
>> santosh <(E-Mail Removed)> writes:
>>
>>> Richard wrote:
>>>
>>>> santosh <(E-Mail Removed)> writes:
>>>>
>>>>> 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.

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

>
> Though it's virtually non-existent today, it's always possible that
> memory-to-memory processors could make a comeback. Also under RISC CPUs
> like the Itanium it will become _very_ tedious and error prone for the
> programmer to keep track of register allocation.
>
> Also keep in mind that a source which makes use of your proposal will


I do keep it in mind. Hence what i said about programmatically
determining the possibilities.

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

>
> In summary I think, (though I may very likely be wrong), that an effort
> for Standardising further constraints for register is likely to be
> complex and ambiguous. Further I don't think there is enough demand in
> the C programming community for this to justify the demand on
> implementors and potential loss in portability.


How many more times : there would be no loss in portability if done
properly.

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

>>
>> I am not talking about the standard. But I would document a procedure
>> which implementations should follow in the standard where the
>> registers can be queried and assigned and forced if necessary.

>
> 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?

>
> <snip>

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

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-06-2007
Richard <(E-Mail Removed)> writes:
> santosh <(E-Mail Removed)> writes:
>> Richard wrote:
>>> santosh <(E-Mail Removed)> writes:
>>>> 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) 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
 
Keith Thompson
Guest
Posts: n/a
 
      10-06-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.


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) (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
 
santosh
Guest
Posts: n/a
 
      10-06-2007
Richard wrote:
> santosh <(E-Mail Removed)> writes:
>> Richard wrote:
>>> santosh <(E-Mail Removed)> writes:


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

 
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