Well, I found part of the problem - the Keil compiler initializes the
memory accelerator module (MAM) in their automatically-generated
startup.s file.  I took it out of there and put the initialization in
main.c, and now the Keil and WinARM are much closer, but the Keil still
looks to be about twice as fast.

Any other ideas would be welcomed!

Randall Aiken

Randall Aiken wrote:
>I took it out of there and put the initialization in
> main.c, and now the Keil and WinARM are much closer, but the Keil still
> looks to be about twice as fast.

I ran across a problem once that made me think I was running much slower
than I actually was; for loops.  I calculated how long each instruction
would take, an executed a for loop to try and estimate my speed.  On
WinArm, I noticed it was actually about 10 times slower than I had
estimated it to be.  This may be a function of the GCC compiler, the
optimization level I was running at (1) and who knows what else.  Its
entirely possible that the Keil compiler is optimizing the for loop
different than GCC (perhaps a difference between thumb and arm mode), so
that although you are actually running at 60 MHz, the Keil codes faster
for loop makes it look like you are going fast.

Then again, you may have messed up initialization in WinArm :)

I suggest you post your start up file where you initialize clock stuff.
I've never used any LPC processors, but I'm sure someone else here has
and may be able to help you.

Jim Kaz wrote:
> I ran across a problem once that made me think I was running much slower
> than I actually was; for loops.  I calculated how long each instruction
> would take, an executed a for loop to try and estimate my speed.  On
> WinArm, I noticed it was actually about 10 times slower than I had
> estimated it to be.  This may be a function of the GCC compiler, the
> optimization level I was running at (1) and who knows what else.  Its
> entirely possible that the Keil compiler is optimizing the for loop
> different than GCC (perhaps a difference between thumb and arm mode), so
> that although you are actually running at 60 MHz, the Keil codes faster
> for loop makes it look like you are going fast.
>
> Then again, you may have messed up initialization in WinArm :)
>
> I suggest you post your start up file where you initialize clock stuff.
> I've never used any LPC processors, but I'm sure someone else here has
> and may be able to help you.


After a bit more thought late last night, I came to the same conclusion.
Today I am going to write a routine that just toggles a pin in an
infinite loop.  I'll stick the oscilloscope on the pin and measure the
frequency.  This will take the delay loop and any optimization out of
the equation (I think!).  If nothing else, it will tell me exactly what
the frequency difference is.

Thanks!

Randall Aiken

Now it gets interesting...

I put in the following code:

  while(1)
  {
    IOCLR0 |= P0_STATUS_LED_o;
    IOSET0 |= P0_STATUS_LED_o;
  }


The Keil compiler executes this at a 1.44MHz toggle rate.

The WinArm compiler executes the same routine at a 1.58MHz toggle rate,
so it is actually faster than Keil!

So, I guess it is indeed a loop optimization problem, although I would
have thought the above code would have run at the same speed regardless
of the compiler.

Thanks!

Randall Aiken

Randall Aiken wrote:
> Now it gets interesting...
>
> I put in the following code:
>
>   while(1)
>   {
>     IOCLR0 |= P0_STATUS_LED_o;
>     IOSET0 |= P0_STATUS_LED_o;
>   }
>
>
> The Keil compiler executes this at a 1.44MHz toggle rate.

Try to use RealView, it's the compiler (better toolchain) RV-MDK from
Keil uses "behind" the uVision IDE.

> The WinArm compiler executes the same routine at a 1.58MHz toggle rate,
> so it is actually faster than Keil!

There is no WinARM compiler. The WinARM package just includes a
precompiled GNU cross-compiler for ARM. Try to use "arm-elf-gcc Version
x.x.x"

> So, I guess it is indeed a loop optimization problem, although I would
> have thought the above code would have run at the same speed regardless
> of the compiler.

For GNU you can output the assembler-code the compiler generates or
create a disassembly from the elf-file (objdump "lss-file"). IRC
RealView also creates elf-binaries so you can objdump this too and
compare the assembly-code and see which kind of optimization has been
done. I think there is also an option in uVision to enable
assembler-listings

When looking at code for RealView or the IAR EWARM toolchain I sometimes
think that both have some kind of "forgotten volatile protection" which
might decrease speed since values are updated in RAM too and not only in
a core-register. But this is just speculation, the (dis)assembly will
show the difference.

Martin Thomas