Lpc2000

Hi Robert

I'm still not convinced and did some more tests. As reference I am 
testing using Visual C++ compiler [for clarification I prefer to 
develop on the PC where the hardware is simulated and then compile 
for the target when it all seems to work - this tends to be much 
faster than debugging on the target and is only an issue when new 
hardware features have to be integrated..(for example finding out 
the issue with SSEL pul up..)]

So here we go:

First simple comparison tests to ensure that the syntax should be 
valid..

extern int iArray[];
extern int *ptr;  // note that ptr is externally set to iArray using 
either ptr = iArray or ptr = &iArray[0];

iArray[20] = 99;
ptr[20] = 100;
ptr += 20;
*ptr = 101;
When I step throug the code I get the confirmation that the same 
address in memory is set to 99 then 100 and then 101, confirming 
that the access to the array is functioning using the three 
different methods.

Then I studied the code which was not working on the target compiled 
with IAR.

Here is what happens with Visual studio C++ compiler (whith assemble 
commented by myself).

extern IDINFO que_ids[];

que_ids[usDriverID].ulEntryAddress = entry_add;
00403A57   mov         edx,dword ptr [ebp-4]        // load usDriver 
value to edx
00403A5A   and         edx,0FFFFh                   // mask to 
unsigned short
00403A60   imul        edx,edx,14h                  // calculate 
offset from start of array (IDINFO is 0x14 long)
00403A63   mov         eax,[_que_ids (0042c684)]    // load the 
start address of que_ids to eax
00403A68   mov         ecx,dword ptr [ebp-14h]      // load the 
value in entry_add to ecx
00403A6B   mov         dword ptr [eax+edx],ecx      // store 
entry_add value from ecx to que_ids start + (offset IDINFO length * 
usDrive)

and here is what happens with the other declaration

extern IDINFO *que_ids;  // Note que_ids = &que_ids_array[0];

00403A45   mov         eax,dword ptr [ebp-4]        // load usDriver 
value to edx
00403A48   and         eax,0FFFFh                   // mask to 
unsigned short
00403A4D   imul        eax,eax,14h                  // calculate 
offset from start of array (IDINFO is 0x14 long)
00403A50   mov         ecx,dword ptr [ebp-14h]      // load the 
value in entry_add to ecx
00403A53   mov         dword ptr _que_ids (0042c684)[eax],ecx  // 
store entry_add value from ecx to que_ids pointer address + (offset 
IDINFO length * usDrive)

As can be seem the second solution is slightly more efficient 
because it is not necessary to load the start address of que_ids 
since it is already in the variable called que_ids. An offset to the 
entry in the structure/array can be accessed directly.

Maybe there was confusion since I didn't point out that que_ids is 
of course initialised with the address of an array (which is 
dynamically allocated using malloc in the real case).

Therefore my conclusion is that the Visual C++ compiler treats these 
two cases as 'equivalent' and can possibly even be more efficient 
using the second declaration (where of course the pointer value is 
set to the start of the array in question).

Do you not agree that then the IAR compiler should therefore produce 
assembler code which works and doesn't cause the system to fail?

Regards

Mark Butcher

www.mjbc.ch

PS I will look at the IAR assembler again later - maybe there is an 
explaination in the details...

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 04:42 PM 2/23/05 +0000, Mark Butcher wrote:
> >extern IDINFO que_ids[]; and extern IDINFO *que_ids; should be
> >equivalent as far as I am aware and this is the first instance 
where
> >I have found two compilers producing completely different code 
(one
> >seemingly false).
> 
> They are not equivalent.  The first is the name of an array, the 
second is 
> a pointer to an element.  The first gets replaced by the linker 
with a 
> reference to the array location in memory, the second by a 
reference to a 
> pointer to a location in memory.
> 
> What you are probably thinking of are the fact that array syntax 
and 
> pointer syntax can be used interchangeably in many circumstances.  
This is 
> one of the exceptions.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to
> chew a radio signal. "
> 
>                          Kelvin Throop, III