Thread: Pointers+arrays

Originally Posted by obaid

Sir,
its not a assembly language problem , its a memory adressing management problem which hv to face the complier. okz

What do you mean? Calculating the address of x[4] or calculating address of x[0] and index with 4 * sizeof(int) are really equivalent in the computers mind.

There are of course differences in some processor architectures which may make one or the other more efficient, but as long as the compiler can sort out that the code isn't going to be affected by "changing from one form to the other", it can do so.

Unless you specifically KNOW that the compiler generates particularly bad code for some PARTICULAR code, you can assume that any array references that can be easier/better solved with a temporary pointer variable, the compiler will use a temporary pointer.

However, if you start adding extra variables for the reason that you think the compiler won't solve the problem, you may find that the compiler generates WORSE code.

_IF_ you play around with code in this way, make sure:
1. That you retain the original code for future versions of the compiler, where it does compile it properly.
2. Verify that your code actually DOES run faster - and that the difference is noticable - reducing the prologue of a for-loop by one cycle in a loop that runs 2000 times isn't worth it.
3. Make CLEAR comments on why you do this.
4. Keep track of whether the next version of compiler actually does it equally well.
5. Make sure you are optimizing code that matters.

--
Mats

Originally Posted by laserlight

If not, how can your example possibly be valid when even at machine level both programs do exactly the same thing?

Well put.

--
Mats

I'm not sure it's as easy as "give me an example of where I'm wrong". First of all, the rules cpjust gives are useful - if your application runs in half a second, most people won't care if you get it down to a quarter second. Obviously, if it takes half a minute or more, there may be room for improvement. In this, find the part of code that runs for the longest time and try to find a way to make that run faster.

But the important rule here is also that "it's hard to beat the compiler".

And just to prove the point:

Code:

int func1(int *x)
{
    int *ptr = &x[4];
    int ans = *ptr + *(ptr+1);
    return ans;
}

int func2(int *x)
{
    int ans = x[4] + x[5];
    return ans;
}
// Sample Program A
int main()
{
    int x[10] = {0};
    int i;
    for(i = 0; i < 10; i++) {
      x[i] = i;
    }
    printf("func1: &#37;d, func2: %d\n", func1(x), func2(x));
    return 0;
}

becomes [snipped for brevity]:

Code:

_func1:
	movl	4(%esp), %edx
	movl	20(%edx), %eax
	movl	16(%edx), %ecx
	addl	%ecx, %eax
	ret
.globl _func2
_func2:
	movl	4(%esp), %edx
	movl	20(%edx), %eax
	movl	16(%edx), %ecx
	addl	%ecx, %eax
	ret

This is from gcc 3.4.2, with -fomit-frame-pointer -O3.

So the difference between your two examples is absolutely NOTHING. Just a bit more C-code and harder to understand in example one, which isn't a benefit.

As I have said before, there are different processor architectures, and some C constructions may be more or less efficient in some ways, but as long as the result is correct, the compiler can pretty much do as it likes with how it generates the actual code.

It is entirely possible to make the compiler generate WORSE code by "confusing the compiler", e.g. using more variables and making things more complex.

--
Mats