Lpc2000

Don't limit yourself to integers.  Those LPC's shine in floating 
point math, which is a place few PIC's and such dare to go.

I did some comparisons on the type of real world calculations I use, 
comparing the same code on a LPC-2106 at 59mHz compiled with GCC in 
CrossWorks, and a 16-bit Freescale MC9S12 processor at 25mHz, 
compiled on CodeWarrior.

The following code snippets are the interiors of a for(;;) loops.  
The times are in microseconds per iteration, including the for() loop 
overhead.  The variable "i" is a 32 bit int for the LPC-2106, and a 
16 bit int for the MC9S12...

for (i = 0; i < 32767; i++)...

There are no optimizations, and I am confident all the code is 
actually present and being executed for both processors.

Both CPU's execute out of on-board flash.

volatile float f1,f2,f3;

//********************************
f1 = (float) i + 1;
f2 = f1 * 3.0f;
f3 = f1 / f2;

LPC-2106, 10usec / iteration
MC9S12, 32usec/iteration
//********************************
f1 = (float) i;
f2 = sqrtf(f1);

LPC-2106, 38usec / iteration
MC9S12, 260usec / iteration
//********************************
f1 = (float) (i & 0x7fff);
f2 = cosf(f1);

LPC-2106, 59usec / iteration
MC9S12, 410usec / iteration
//********************************

On a math intensive splining algorithm the LPC-2106 is about 4.5 
times faster than the MC9S12.

Times on a 59mHz LPC-2214 seem to be identical to the LPC-2106.

Naturally there are some caveats, such as CodeWarrior seems to make 
calls do double precision cos() from within its cosf() function.  But 
I just call 'em as I seem 'em.

Aside from the fast floating point, I am also impressed by the speed 
with which GNU converts between float and int, which is bread and 
butter for my applications and a place where some compilers I have 
used are very weak.

Bottom line...LPC kicks fanny in the world of floating point, if not 
most other places.  And don't turn up your nose at that GNU compiler, 
either!

Bill T.
http://www.kupercontrols.com


--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi "geno" and Charles,
> 
> 
> > I'm not sure I believe some of these numbers. For example, the 32-
bit 
> > subtraction should be way faster on an ARM. I hunch that a lot of 
time 
> > is being chewed up by looping overheads or saving/storing the 
values 
> > (something that is often optimised out in real code) or some 
other 
> > time waster.
> 
> I concur here....
> For example :
> 
> 
> 
> 
> Test                      Philips               Atmel AVR          
Microchip   TI
>                             LPC2106            (ATMega323)     
PIC18F452   MSP430F449
>                             Flash[RAM]
> 
> 32bit multiply        10.4µs [8.76µs]    180µs            
    
344µs         182µs
> 
> 
> I find it doubtful that an ATMega takes the same amount of time for 
a 32 bit multiply as MSP430.
> (Assuming the same clocks)
> F449 has a 16X16 HW multiply, and AVR has only 8X8 (fract) 
multiply, notwithstanding the 8 vs. 16 bit architecture.
> That is also assuming that a 16 X 16 into 32 bit multiply is 
intended.
> Probably the HW MUL wasn't used on MSP430 ..... silly, since ARM 
has such an instruction, it should be a fair
> equation that HWMUL is used.
> 
> -- Kris
> 
> 
> [Non-text portions of this message have been removed]