Lpc2000

Oppps... I should have seen the binary code -- you *are* generating
32-bit code.

In this case, I think the compiler decided not to use literal pools
for some reason.  May be there is no place nearby to place the pool
constants.

So I really have no idea what it is trying to optimise, if this is
what it is doing!

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- 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. 
> 
> My guess is that you are generating 16-bit code with and compiler is
> minimising code size.  The above three instructions then would occupy
> three 16-bit locations in memory, while the replacement
>  
> >        ldr r2 #e0004018
> 
> would require one 32-bit instruction and another 32-bit to store the
> constant.
> 
> Jaya
>