Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Strange Compiler Behaviour -

2005-02-23 by Mark Butcher

Hi All

Can anyone explain the following?

Here's the code (important fragments only):


***********************************
extern IDINFO que_ids[];

static unsigned short entry_spi(void)
{
return 0;
}

a_function()
{
unsigned short usDriverID = 2;
unsigned short (*entry_add)(void) = entry_spi;

que_ids[usDriverID].ulEntryAddress = entry_add; /* HERE */
}
***********************************
Works fine - /* HERE */ is compiled to the following assembler code 
by IAR compiler.

LDR R0,[PC,#0x090]
SRP R0,[R6,#0]



However when the external que_ids is defined as
extern IDINFO *que_ids;
-----------------------
the program doesn't work any more. If I compile and run the same 
code using Visual C++ however it works also fine.

The IAR compiler creates in this case the following code:
LDR R0,[PC,#0x09c]
LDR R1,[PC,#0x0A0]
LDR R1,[R1,#0]
LDR R2,[SP,#4]
STR R0,[R1,R2]

In fact what it does is uses the value of que_ids[0].ulEntryAddress 
as a reference pointer plus some offset to store the value of 
entry_add and this is somewhere in the middle of RAM no-mans-
land...causing program failure.



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

Any Gurus out there with any comments? Could it be an IAR specific 
problem or is it more delicate than that?

Cheers

Mark Butcher

www.mjbc.ch

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.