Lpc2000

I did a quick experiment that possibly explains what is happening.

--- In lpc2000@yahoogroups.com, Jan Thogersen <jan@...> wrote:
>        E3A0220E   mov r2, #0xE0000000
>        E2822901   add r2, r2, #0x00004000
>        E2822018   add r2, r2, #0x00000018
...
> 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. 

My source code looks like this:

> int
> foo(void)
> {
>         return (0x12345678);
> 
> } // foo()

The -O3 output looks like this:

> e59f0000        ldr     r0, [pc, #0]
> e1a0f00e        mov     pc, lr
> 12345678        .word   0x12345678

Changing return value to 0x12005678 gives:

> e3a02412        mov     r2, #0x12000000
> e2821c56        add     r1, r2, #0x5600
> e2810078        add     r0, r1, #0x78
> e1a0f00e        mov     pc, lr

The logic seems to be that if the constant can be loaded with MOV or
MOV plus up to two ADD instructions, GCC prefers this sequence to LDR.

It is possible that MOV plus two ADDs is more optimal than LDR taking
into account speed and size, possibly because of instruction cache
penalty when fetching memory pool constants in LDR case.

I dont know if anyone has added -mcpu for LPC that could use a
different cost table given MAM does not necessarily incur speed
penalty in accessing memory pool constants.

Jaya