Another silly question

[Simon A Reap]

In article <155 at titania.warwick.ac.uk> cudcv at warwick.ac.uk (Rob McMahon) writes:
>In article <756 at mccc.UUCP> pjh at mccc.UUCP (Pete Holsberg) writes:
>>Perhaps I've asked the wrong question.  I saw a couple of simple test
>>programs that assigned 0 to each member of an array.  One used array
>>subscript notation, and the other, pointer notation ...  The subscript
>>versions had different run times from the pointer versions (some slower, some
>>faster!).  I assumed - perhaps naively - that the differences were caused by
>>differences in code produced by the different compilers (and of course the
>>hardware differences).
>
>I'll lay odds that you're comparing
>
>	int i;
>	for (i = 0; i < MAX; i++)
>		a[i] = 0;
>with
>	grimble *p;
>	for (p = a; p < &a[MAX]; p++)
>		*p = 0;
>
>am I right?
>

Compiling:
int a[20];
main(){int i;
for(i=0;i<20;i++)a[i]=0;
f();
for(i=0;i<20;i++)*(a+i)=0;
f();
}

on our Pyramid 9820 gives the following assembler in att and ucb universes:
	movw	$0x0,lr0
	br	L13
L15:
	movw	$0x0,_a[lr0*0x4]             ;body of loop for a[i]=0
	addw	$0x1,lr0                     ;
L13:
	cmpw	$0x14,lr0
	blt	L15
L14:
	call	_f
	movw	$0x0,lr0
	br	L16
L18:
	mova	_a[lr0*0x4],pr2              ;body of loop for *(a+i)=0
	movw	$0x0,(pr2)                   ;
	addw	$0x1,lr0                     ;
L16:
	cmpw	$0x14,lr0
	blt	L18
L17:
	call	_f
	ret	

Yup, different code.  But then again, what can one expect from a compiler
that doesn't understand i[a] (as in "hello"[2]) :-(  Such a pity on an
otherwise good machine.


-- 
Enjoy,
yerluvinunclesimon             Opinions are mine - my cat has her own ideas
Reach me at sar at datcon.co.uk, or ...!mcvax!ukc!pyrltd!datcon!sar