Register Variable Managment

I apoligise in advance if this is an os or platform based question, I
don't know.

I was wondering how register integers (and other types of register
variables) are managed by c++. For example, on a pentium 4, there are
8 register integers in the cpu. If you define more than 8, or if there
are other programs using this space, how are the variables allocated.
This is for a simulation program that needs to be very fast.
For example:

int foo()
{
register int a;
register int b;
register int c;
register int d;
register int e;
register int f;
register int g;
register int h;
register int i;

//Code using register ints

return 1;
}

There are 9 register integers defined, and, assuming you have only 8 on
your platform, will, after you have defined more than 8, the first one
be put into normal memory or is there some other system for allocating
them.
Also, in for loops, is the counting variable by default a register int.
I have done several tests and the time for a for loop defined like
this:

for( int n = 0; n < 10000; n++ )
{
//Code
}

for( register int n = 0; n < 10000; n++ )
{
//Code
}

is the same.

Thanks
-Alex

"Alex" <alex.fake@gmail.com> wrote...[color=blue]
>I apoligise in advance if this is an os or platform based question, I
> don't know.[/color]

It's not platform-based. It is, however, implementation-defined.
[color=blue]
> I was wondering how register integers (and other types of register
> variables) are managed by c++. For example, on a pentium 4, there are
> 8 register integers in the cpu. If you define more than 8, or if there
> are other programs using this space, how are the variables allocated.
> This is for a simulation program that needs to be very fast.
> For example:
>
> int foo()
> {
> register int a;
> register int b;
> [...][/color]

'register' just like 'inline' is not a directive, but rather a suggestion
for your compiler. It may take a hint and try placing the object in a CPU
register, or it may decide against it and do whatever it sees fit. Just
like you noticed, it's not always possible, besides, it's not always the
desired course of action.

One thing you should probably learn at this point: compilers are better at
deciding what needs to go where than programmers. So, spend your time on
_algorithms_ and getting things _right_, before ever attempting to get them
"very fast". Let the compiler decide what registers to use and when. Do
_not_ concern yourself with performance of your code on any particular CPU
type or model; instead concern yourself with portability and maintainability
of your code. IOW, forget the "register" keyword exists or what it's for,
except that you're not allowed to use it anywhere else. Trust me, your life
will be simpler that way.

Victor

Victor Bazarov wrote:[color=blue]
> "Alex" <alex.fake@gmail.com> wrote...
>[color=green]
>>I apoligise in advance if this is an os or platform based question, I
>>don't know.[/color]
>
>
> It's not platform-based. It is, however, implementation-defined.
>
>[color=green]
>>I was wondering how register integers (and other types of register
>>variables) are managed by c++. For example, on a pentium 4, there are
>>8 register integers in the cpu. If you define more than 8, or if there
>>are other programs using this space, how are the variables allocated.
>>This is for a simulation program that needs to be very fast.
>>For example:
>>
>>int foo()
>>{
>>register int a;
>>register int b;
>>[...][/color]
>
>
> 'register' just like 'inline' is not a directive, but rather a suggestion
> for your compiler. It may take a hint and try placing the object in a CPU
> register, or it may decide against it and do whatever it sees fit. Just
> like you noticed, it's not always possible, besides, it's not always the
> desired course of action.
>
> One thing you should probably learn at this point: compilers are better at
> deciding what needs to go where than programmers. So, spend your time on
> _algorithms_ and getting things _right_, before ever attempting to get them
> "very fast". Let the compiler decide what registers to use and when. Do
> _not_ concern yourself with performance of your code on any particular CPU
> type or model; instead concern yourself with portability and maintainability
> of your code. IOW, forget the "register" keyword exists or what it's for,
> except that you're not allowed to use it anywhere else. Trust me, your life
> will be simpler that way.
>
> Victor
>
>[/color]

However, one can always assist a compiler by writing code that
makes the decisions easier for the compiler.

For example, if a processor has a string search instruction, a
person may want to set up the code so that the compiler recognizes
the "pattern" and implements the string search function.

I've done this on the ARM processor using registers and its
special transfer instructions.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

Thomas Matthews wrote:[color=blue]
> Victor Bazarov wrote:
>[color=green]
>> "Alex" <alex.fake@gmail.com> wrote...
>>[color=darkred]
>>> I apoligise in advance if this is an os or platform based question, I
>>> don't know.[/color]
>>
>>
>>
>> It's not platform-based. It is, however, implementation-defined.
>>
>>[color=darkred]
>>> I was wondering how register integers (and other types of register
>>> variables) are managed by c++. For example, on a pentium 4, there are
>>> 8 register integers in the cpu. If you define more than 8, or if there
>>> are other programs using this space, how are the variables allocated.
>>> This is for a simulation program that needs to be very fast.
>>> For example:
>>>
>>> int foo()
>>> {
>>> register int a;
>>> register int b;
>>> [...][/color]
>>
>>
>>
>> 'register' just like 'inline' is not a directive, but rather a suggestion
>> for your compiler. It may take a hint and try placing the object in a
>> CPU
>> register, or it may decide against it and do whatever it sees fit. Just
>> like you noticed, it's not always possible, besides, it's not always the
>> desired course of action.
>>
>> One thing you should probably learn at this point: compilers are
>> better at
>> deciding what needs to go where than programmers. So, spend your time on
>> _algorithms_ and getting things _right_, before ever attempting to get
>> them
>> "very fast". Let the compiler decide what registers to use and when. Do
>> _not_ concern yourself with performance of your code on any particular
>> CPU
>> type or model; instead concern yourself with portability and
>> maintainability
>> of your code. IOW, forget the "register" keyword exists or what it's
>> for,
>> except that you're not allowed to use it anywhere else. Trust me,
>> your life
>> will be simpler that way.
>>
>> Victor
>>[/color]
>
> However, one can always assist a compiler by writing code that
> makes the decisions easier for the compiler.
>
> For example, if a processor has a string search instruction, a
> person may want to set up the code so that the compiler recognizes
> the "pattern" and implements the string search function.
>
> I've done this on the ARM processor using registers and its
> special transfer instructions.[/color]

Oh, there is no doubt about it. The point[s] of my post was/were that
(a) 'register' is not the way to do that, (b) before attempting doing that
one should understand the inner workings of the compiler/CPU combination
very well and (c) portability and maintainability are often more important
than minute improvements in performance: productivity is not measured by
the performance of a single program fragment but by the overall output of
the [sometimes quite large] group of people that involves using and
advancing that program (and I am not sure if I read it somewhere or that
I just made it up :-).

Victor