Lpc2000

brendanmurphy37 wrote:

> 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? 

The whole sequence might have been even better as:

   mov r2, #0xE0000000
   add r2, r2, #0x00004000
   add r2, r2, #0x00000018
   mov r3, [r2]
   add r3, r3, #0x00000001
   str r3, [r2]

But if you REALLY are that short of cycles, maybe inline assembler
is a better choice. (Kidding)

The buf_inpos and buf_outpos are still a mystery. One looks like it's
being loaded from a fixed value that's stored close by in code space:

   ldr r3, [pc, #304]

while the other looks like it's coming off the stack frame:

   ldr r1, [r11, #-28]

Ralph

> 
> 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
>>
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
>