Experiences using "register"

[Ioannis Vranos]

Because it adversely affects code size is one thing I can think of ...

Exactly. "register" should be used in as a small scope as possible, so
as it affects (or better: doesn't affect) code that is not intended to
be affected.

 

[Ioannis Vranos]

Corrected:



Exactly. "register" should be used in as a small scope as possible, so
as it doesn't affect code that is not intended to be affected.

 

[Harald van Dijk]

Because it adversely affects code size is one thing I can think of ...

If the function is huge, but it's only called from one place, inlining
may even decrease the code size.

 

[Ioannis Vranos]

If the function is huge, but it's only called from one place, inlining
may even decrease the code size.

Still, you don't know how many times it will be called in the future, so
it is a bad practice.

 

[Harald van Dijk]

Still, you don't know how many times it will be called in the future, so
it is a bad practice.

Yes, I do, if it's something like the main loop of an event-driven
program, or library initialisation. It doesn't make any sense to call
that more than once, or from different locations.

 

[Richard]

Exactly. "register" should be used in as a small scope as possible, so
as it affects (or better: doesn't affect) code that is not intended to
be affected.

You could have a function 100 lines long where the register variable is
used on every line and its use does not impede the rest of the code.

 

[Willem]

Ioannis wrote:
) Exactly. "register" should be used in as a small scope as possible, so
) as it doesn't affect code that is not intended to be affected.

Here, again, you say 'as small a scope as possible'.
That _doesn't_ necessarily mean 'a small scope'.

You *still* haven't given any reason why 'register' should only
be used on _small scopes_. You're just going in circles.

Again: 'as small a scope as possible' is *NOT* the same as 'small scope'.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Willem]

Ioannis wrote:
) Willem wrote:
)> You're arguing in circles again.
)> Why should 'register' be used only when it has minimal effect on the code ?
)
) Why "inline" should be used with small functions only?

You tell me. I sometimes use it on quite large functions.

And besides, what does that have to do with 'register' ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Ioannis Vranos]

Ioannis wrote:
) Exactly. "register" should be used in as a small scope as possible, so
) as it doesn't affect code that is not intended to be affected.

Here, again, you say 'as small a scope as possible'.
That _doesn't_ necessarily mean 'a small scope'.

You *still* haven't given any reason why 'register' should only
be used on _small scopes_. You're just going in circles.

Again: 'as small a scope as possible' is *NOT* the same as 'small scope'.

OK, we have a comprehension problem. Replace my phrase "as small a scope
as possible" with "a small scope".

 

[Ioannis Vranos]

You could have a function 100 lines long where the register variable is
used on every line and its use does not impede the rest of the code.

.... theoretically speaking.

 

[Ioannis Vranos]

Yes, I do, if it's something like the main loop of an event-driven
program, or library initialisation. It doesn't make any sense to call
that more than once, or from different locations.

This reminds me something I have read elsewhere. Something like "no rule
is so general that it has no exceptions".

In any case, how much size will you save if you make this one-called
function inlined? The same minus a function call (an address) in the
automatic storage.

 

[santosh]

Ioannis wrote:
) Richard wrote:
)>> If the function is more than 5-6 lines of code, "register" should
not be )>> used for the function scope but only for local scopes in
the function )>> (like small loops).
)>
)> Where do you get these "facts" that you maintain are true with zero
to )> back them up? It all depends on the compiler and also depend, in
a )> larger function, on how often your register variable was used and
how it )> was used. Length in lines has absolutely nothing to do with
it. )
) The smaller the scope, the less effect it has on the rest of code.
Where ) do you disagree with this?

You're arguing in circles again.
Why should 'register' be used only when it has minimal effect on the
code ?

He probably means minimal adverse effect (WRT efficiency) on the rest of
the code.

The only true way to determine the effectiveness of register and it's
effects on code surrounding it is to compile it for a particular
implementation and examine the assembler so generated. To determine
with even more assurance you'll have to see the source for the
compiler, or at least the relevant portions.

It's possible that register will influence the code generated and how
exactly it does so depends on the exact code, compiler flags, and the
register allocation algorithms used by the compiler.

A trivial example could be that declaring an object with register forced
the compiler to load and store from memory some other object that would
otherwise have benefited from being in a register.

Consider a case of a nested loop:

for (register int i = 0; i < UPPER_BOUND; i++) {
for (int j = INIT_VALUE; j > 0; j--) {
/* do something */
}
}

Now any decent compiler will try to place 'j' in a register in
preference over 'i', but it may be that it decided to heed the
programmer's suggestion and used a register for 'i', with a probable
loss in performance. I seriously doubt that any compiler is this bad. I
think that if they determine that an explicit use of register is
causing more loads and stores than otherwise, they just ignore the
suggestion.

 

[Richard]

... theoretically speaking.

Practically speaking actually.

 

[Ioannis Vranos]

He probably means minimal adverse effect (WRT efficiency) on the rest of
the code.

The only true way to determine the effectiveness of register and it's
effects on code surrounding it is to compile it for a particular
implementation and examine the assembler so generated. To determine
with even more assurance you'll have to see the source for the
compiler, or at least the relevant portions.

It's possible that register will influence the code generated and how
exactly it does so depends on the exact code, compiler flags, and the
register allocation algorithms used by the compiler.

A trivial example could be that declaring an object with register forced
the compiler to load and store from memory some other object that would
otherwise have benefited from being in a register.

Consider a case of a nested loop:

for (register int i = 0; i < UPPER_BOUND; i++) {
for (int j = INIT_VALUE; j > 0; j--) {
/* do something */
}
}

Now any decent compiler will try to place 'j' in a register in
preference over 'i', but it may be that it decided to heed the
programmer's suggestion and used a register for 'i', with a probable
loss in performance. I seriously doubt that any compiler is this bad. I
think that if they determine that an explicit use of register is
causing more loads and stores than otherwise, they just ignore the
suggestion.

Yes you are right. However if one "register" was to be used, the
programmer should have declared j (the smaller scope) instead of i.

 

[santosh]

This reminds me something I have read elsewhere. Something like "no
rule is so general that it has no exceptions".

In any case, how much size will you save if you make this one-called
function inlined? The same minus a function call (an address) in the
automatic storage.

The main purpose of inline is to take away the function call and return
overhead, and this can make sense only for a function that is very
small and finishes very quickly, and is called often, or if the
performance of that function is critical. Otherwise the code for the
function is going to swamp any benefit from shaving of the call/return
instructions. Using inline for affecting code size is, IMO, misusing
it. Again the standard inline keyword is like register: just a hint. A
macro is going to give you an assurance of inlining at the cost of loss
of parameter type checking, or you might try compiler specific options
to force inlining of certain functions.

 

[santosh]

Yes you are right. However if one "register" was to be used, the
programmer should have declared j (the smaller scope) instead of i.

For this simple case yes. But my point was that with modern compilers
it's likely that the compiler can allocate registers better than what
the programmer can do, so register declarations are most likely to be
ignored, or if they are not, may interfere with the compiler's register
allocation and actually lead to less efficient code.

Of course, the real point is that the effect of register can only be
determined by testing.

 

[Willem]

Ioannis wrote:
) Willem wrote:
)> Ioannis wrote:
)> ) Exactly. "register" should be used in as a small scope as possible, so
)> ) as it doesn't affect code that is not intended to be affected.
)>
)> Here, again, you say 'as small a scope as possible'.
)> That _doesn't_ necessarily mean 'a small scope'.
)>
)> You *still* haven't given any reason why 'register' should only
)> be used on _small scopes_. You're just going in circles.
)>
)> Again: 'as small a scope as possible' is *NOT* the same as 'small scope'.
)
) OK, we have a comprehension problem. Replace my phrase "as small a scope
) as possible" with "a small scope".

If you make that replacement, then suddenly your statement doesn't sound
so self-evident any more, as I already indicated.

So answer the question above: *WHY* should 'register' only be used
on small scopes ? If I use it on a large scope, then I *intend* that
it affects a lot of code. I see no reason why I shouldn't do that.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Willem]

santosh wrote:
) Ioannis Vranos wrote:
)> In any case, how much size will you save if you make this one-called
)> function inlined? The same minus a function call (an address) in the
)> automatic storage.
)
) The main purpose of inline is to take away the function call and return
) overhead, and this can make sense only for a function that is very
) small and finishes very quickly, and is called often, or if the
) performance of that function is critical. Otherwise the code for the
) function is going to swamp any benefit from shaving of the call/return
) instructions. Using inline for affecting code size is, IMO, misusing
) it. Again the standard inline keyword is like register: just a hint. A
) macro is going to give you an assurance of inlining at the cost of loss
) of parameter type checking, or you might try compiler specific options
) to force inlining of certain functions.

A secondary, but very important, reason for inlining large functions is to
give the optimizer more things to work with, and therefore a better chance
to optimize the code. Take this example:

/* some code */
verylargefunction(25, 3, &args);
/* some more code */
verylargefunction(35, 2, &moreargs);
/* and some other code */
verylargefunction(10, 0, NULL);
/* and a bit more code */

Now, verylargefunction() is a very large function that does a lot of work.
It is called three times, with constants as parameters.
By inlining the function, the compiler can suddenly do lots and lots of
constant expression evaluation inside verylargefunction().
Note also the NULL parameter at the third call. Suppose that inside
verylargefunction(), that parameter is used often to store results,
except when it's NULL. That is, each access has code similar to:
if (param3) param3[x]=y;
If this function is inlined, all those if-statements are optimized away,
and for the third call, the accesses are optimized away as well.

This is a huge reason for marking large functions inline.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Ioannis Vranos]

)
) OK, we have a comprehension problem. Replace my phrase "as small a scope
) as possible" with "a small scope".

If you make that replacement, then suddenly your statement doesn't sound
so self-evident any more, as I already indicated.

So answer the question above: *WHY* should 'register' only be used
on small scopes ? If I use it on a large scope, then I *intend* that
it affects a lot of code. I see no reason why I shouldn't do that.

The intention of using "register" is per variable. Having "register"
used in small scopes you avoid unwanted side-effects on the rest of code
as mentioned by others.

 

[Willem]

Ioannis wrote:
) The intention of using "register" is per variable. Having "register"
) used in small scopes you avoid unwanted side-effects on the rest of code
) as mentioned by others.

That sounds like a 'rule of thumb', or like 'good practise'.

But this thread started with your mention of 'proper use'.
Are you saying that 'proper use' is the same as 'good practise',
and that any exception to the rule, no matter how appropriate
or intended, is not 'proper use' ?

For example, if a variable is heavily used throughout the function,
for several different purposes, I consider it a good idea to declare
that variable 'register'. For the entire function.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT