Thread: Register and For loop

I have two different questions:

1. I have got a book: C The Complete Reference. It says when I declare a variable as register it can be accessed faster. Also I don't need to worry about the limit, because compiler stores some variables unregistered if the limit is reached. Then isn't there any disadvantage of register. Should I declare all local variables as register?

2. There is a for loop:

Code:

int int pwr(register int m, register int e)
{
register int temp;
temp = 1;
for(; e; e--) temp = temp * m;
return temp;
}

I haven't understood (; e; e--)

What is the second part of this (e) here. What does it mean?

There's also no advantage to register, as the compiler is not obligated to put anything in a register either.

The second part of the for-loop guard, like all for-loop guards, is the when-to-stop condition. The loop will continue while the second part evaluates true.

Originally Posted by GokhanK

I have two different questions:

1. I have got a book: C The Complete Reference. It says when I declare a variable as register it can be accessed faster. Also I don't need to worry about the limit, because compiler stores some variables unregistered if the limit is reached. Then isn't there any disadvantage of register. Should I declare all local variables as register?

You could but it's not advisable to interfere with optimizations the compiler/assembler can do because they are really good at it.
Assigning locals to registers effectively shuts off those registers from the compiler's reach for code generation and optimisation.

Originally Posted by GokhanK

2. There is a for loop:

Code:

int int pwr(register int m, register int e)
{
register int temp;
temp = 1;
for(; e; e--) temp = temp * m;
return temp;
}

I haven't understood (; e; e--)

What is the second part of this (e) here. What does it mean?

The for loop kicks off with whatever e is passed to pwr(); each loop decrements e until the terminal condition is reached i.e. e == 0.

Originally Posted by tabstop

There's also no advantage to register, as the compiler is not obligated to put anything in a register either.

The second part of the for-loop guard, like all for-loop guards, is the when-to-stop condition. The loop will continue while the second part evaluates true.

Then is the usage of register redundant?

And I think I should give details about my second question:

I have seen for statements as (e=1; e>5; e++), but I don't know what it means when e stands alone.

Originally Posted by GokhanK

Then is the usage of register redundant?

No, but only use it if you know you can out-optimize your compiler, which is doubtful, or you have some other, really, really good reason I can't think of.

I have seen for statements as (e=1; e>5; e++), but I don't know what it means when e stands alone.

The middle expression is evaluated as a boolean expression, where true means keep looping and false means stop the loop. Boolean expressions in C are false when the expression is zero and true for all non-zero values. The expression 'e' just means "the value of e". So your for loop looks like:

Code:

for (no initialization; so long as e is true (non-zero); decrement e)

EDIT: This pseudo code reflects your original loop, not your new bogus one that never executes because e is initialized to 1 and only loops if e > 5.

Originally Posted by anduril462

EDIT: This pseudo code reflects your original loop, not your new bogus one that never executes because e is initialized to 1 and only loops if e > 5.

Yes it is wrong. I should write e<5.

Thanks for your nice reply.

Originally Posted by Salem

The best thing you can do with your book is throw it into the shredder.
bullschildt

It might be an easy read, but then again, most works of fiction without any basis in the real world are designed to be an easy read.

lol!

I can answer you for your second question.

In C, any non-zero integer is considered as true and zero as false. So In the following for loop suppose e has initial value as 5. Then as 5 is non-zero number it will be considered as true and similiarly for 4,3,2,1 but as 0 comes (which means false as i told earlier) will terminate the loop.

Code:

 
for(; e; e--) temp = temp * m;

Originally Posted by CommonTater

It may sound like a really cool optimization, but if not used with caution, it can also introduce subtle, almost untraceable bugs into a program...

I don't think so. In the days where 'register' did what it was claimed to do, up to a maximum of two such uses as I recall, the program did in fact improve performance. If there were oddball address aliasing, the compiler would have noticed it and provided sufficient code to propagate the value into real RAM (from the register) as required. Unless you can point to specific compilers which had known bugs in this regard.

The reference book that was referred to may be out-of-date with today's much more optimizing compilers. Perhaps the keyword 'register' has just been left over for backward compatibility... and as some have commented, its ultimate efficacy is highly questionable. It has been relegated to being a mere suggestion. The compiler can chose to ignore its use in all cases and still be C compliant.

Since we're talking about history, I'm referencing the C89 standard...

Originally Posted by C89 3.5.1

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. (49)

Originally Posted by nonoob

I don't think so. In the days where 'register' did what it was claimed to do, up to a maximum of two such uses as I recall, the program did in fact improve performance.

register still "does what it's supposed to do", which is suggest the compiler make it as fast as possible. The limit of how many register variables you could use effectively was architecture dependent. The SPARC architecture used by Sun had 8 global general purpose registers and 8 local general purpose registers per frame (they had a sexy sliding-frame setup for function calls). The compiler could possibly put 16+ variables in registers.

If there were oddball address aliasing, the compiler would have noticed it and provided sufficient code to propagate the value into real RAM (from the register) as required. Unless you can point to specific compilers which had known bugs in this regard.

Determining the address of a register variable is expressly prohibited, which makes perfect sense since it might not be in memory and thus has no address:

Originally Posted by C89 standard footnote 49

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 may not be computed, either explicitly (by use of the unary & operator as discussed in 3.3.3.2) or implicitly (by converting an array name to a pointer as discussed in 3.2.2.1). Thus the only operator that can be applied to an array declared with storage-class specifier register is sizeof .

As an aside, could you compile your example Tater? What compiler are you using? GCC wouldn't let me...

The reference book that was referred to may be out-of-date with today's much more optimizing compilers. Perhaps the keyword 'register' has just been left over for backward compatibility...

Doubtful. Compiler writers are pretty awesome coders and their optimizations are generally much faster, but not knowing the intent of your code, they can only optimize so much. It's quite possible that you have some intricate knowledge of your algorithm and know you want a specific variable in a register, thus I would wager most decent compilers do their darnedest to honor the keyword, assuming that if you use it, you know what you're doing. Indeed, GCC (v4.4.4) translated the following two declarations differently:

Code:

// foo.c
#include <stdio.h>

int main(void)
{
    int x = 5;
    register int y = 10;
	
    printf("x: %d\n", x);
    printf("y: %d\n", y);

    return 0;
}

gcc -S foo.c

Code:

    movl    $5, 28(%esp) ; this is x, referenced from the stack pointer
    movl    $10, %ebx    ; this is y, stored directly in a register

Originally Posted by anduril462

Doubtful. Compiler writers are pretty awesome coders and their optimizations are generally much faster, but not knowing the intent of your code, they can only optimize so much. It's quite possible that you have some intricate knowledge of your algorithm and know you want a specific variable in a register, thus I would wager most decent compilers do their darnedest to honor the keyword, assuming that if you use it, you know what you're doing. Indeed, GCC (v4.4.4) translated the following two declarations differently:

Code:

// foo.c
#include <stdio.h>

int main(void)
{
    int x = 5;
    register int y = 10;
	
    printf("x: %d\n", x);
    printf("y: %d\n", y);

    return 0;
}

gcc -S foo.c

Code:

    movl    $5, 28(%esp) ; this is x, referenced from the stack pointer
    movl    $10, %ebx    ; this is y, stored directly in a register

Try this with any level of optimization and you'll see the compiler ignore the keyword. No fair testing how the compiler optimizes code with the optimizer turned off.

Code:

	movl	$5, 4(%esp)
	movl	$LC0, (%esp)
	call	_printf
	movl	$10, 4(%esp)
	movl	$LC1, (%esp)	 #,
	call	_printf

Identical treatment for x and y - both are constants pushed onto the stack before calling printf(). From what I've seen, the GCC devs say that with optimization turned on GCC ignores the keyword register. Their take seems to be that "produce the fastest code possible for this var" is "let the compiler do whatever it deems best and not let the user interfere".