Lpc2000

Jan,

There's certainly something strange going on here.

As others have pointed out you can't load a 32-bit literal with the 
syntax you suggest. It can do done either with something like a 
load/shift/add over one or more instructions as is the case here, or 
loading indirect, as in:

 ldr pc, do_reset_addr

do_reset_addr: .long do_reset

(i.e. the 32-bit literal value is stored nearby).

That much is normal.

However, the something strange is more that you say the compiler 
optimisation is at level 3, yet it loads identical literal values 
into both r2 and r3 for no apparent reason.  GCC is normally very 
good at optimisation.

What way is TMR0 declared? Is "volatile" involved at all?

Also the initial comparison looks a bit strange: what way are 
buf_inpos and buf_outpos declared? 

Brendan


--- In lpc2000@yahoogroups.com, Jan Thogersen <jan@...> wrote:
>
> Hi,
> 
> Now I'm trying to dig into the assembler generation from the GCC 
> compiler and I've noticed something that I don't quite understand.
> 
> Here is the dump that got my attention:
>     if (buf_inpos == buf_outpos) T0MR0++; else { // The fifo is 
empty
>        E59F3130   ldr r3, [pc, #304]
>        E5D33000   ldrb r3, [r3]
>        E51B101C   ldr r1, [r11, #-28]
>        E1530001   cmp r3, r1
>        1A000009   bne 0x0000093C
>        E3A0220E   mov r2, #0xE0000000
>        E2822901   add r2, r2, #0x00004000
>        E2822018   add r2, r2, #0x00000018
>        E3A0320E   mov r3, #0xE0000000
>        E2833901   add r3, r3, #0x00004000
>        E2833018   add r3, r3, #0x00000018
>        E5933000   ldr r3, [r3]
>        E2833001   add r3, r3, #0x00000001
>        E5823000   str r3, [r2]
>        EA000031   b 0x00000A04
> 
> How come it takes 3 instruction to load the correct address into 
r2. 
> First it moves #0xE0000000 to r2, then adds #0x00004000 and finally 
adds 
> #0x00000018 to end up with #0xE0004018 which is the address of 
T0MR0. 
> But why don't it just move #0xE0004018 into the r2 in the first 
instruction?
> 
> This strange way of loading the mem location is seen throughout the 
hole 
> dump!
> 
> I'm compiling af optimizion level 3.
> 
> Best regards
>   Jan
>