Lpc2000

Hi,

Very interesting benchmark results. It matches our own experience, 
which can be summarised as "good as or better than the alternatives 
in terms of performance (speed and code size), provided you don't use 
the built-in libraries".

Our preference is not to use any compiler libraries in any case, as 
it gives total control of the software. The only part that is 
inconvenient on this is a good implementation of "printf", but even 
that's not too much of a problem to source or implement, and once 
done once is always available.

The same goes for various "extensions": even if you don't expect to 
have to port code or move to a different toolset, you usually end up 
having to do so at some stage, so you're better off sticking to pure 
ANSI 'C' (or something very close to it).

On other issues around compiler choice:

- I've used GCC off and on for maybe 10 years now, and have never 
even heard of an error in the code generated by it, much less 
experienced it. Support in terms of fixing problems hasn't therefore 
ever been an issue.

- I've experienced a few very time consuming bugs in other vendor's 
compilers, especially when used at high optimisation levels. Quality 
of support has varied, but in all cases a lot of time was used up in 
tracking down and fixing the problems.

These two issues (reliability and performance) are in fact the main 
reasons we use GCC: the cost helps of course, but it's really a side 
issue in our case.

The downside of GCC is that it can involve a lot of work to set up 
and use the first time: not something I'd recommend. However, as has 
been pointed out, several of the tool vendors have already done this 
for the LPC2000, so that's not really an issue.

Bottom line: it's very hard to beat the GCC compiler.

Just my opinion, of course....

Brendan



--- In lpc2000@yahoogroups.com, "Jerry [Signum]" <jerry@s...> wrote:
>
> MHaines,
> 
> There is a recent comparison of ARM compile tools from ARM, Keil, 
IAR and GNU at
> http://www.raisonance.com/products/STR7/benchmark.php
> They have all the source files used in the benchmark, so you can 
check your own tools.
> 
> As far as ARM Trace tools, you may want to check out our JTAGjet-
Trace while you
> are comparison shopping - see www.signum.com/jtagjet.htm
> I have not used Vitra but I can answer any questions related to the 
LPC2000 ETM trace
> port in general.
> 
> Jerry
> Signum Systems Corp.
> Moorpark, CA 93021
> www.signum.com
> ========================================
>     26 YEARS OF EMULATION SYSTEMS DESIGN: 
>   8051, ARM, OMAP, 80186, 80196 and TMS320 DSPs
> ========================================
> 
> 
> 
> ----- Original Message ----- 
> From: "mhaines4102" <mhaines4102@y...>
> To: <lpc2000@yahoogroups.com>
> Sent: Thursday, January 12, 2006 4:11 PM
> Subject: [lpc2000] Re: Have any of you used Ashling Trace Debugging
> 
> 
> > Or the Realview tools for that matter. How do they stack up?
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "mhaines4102" <mhaines4102@y...> 
wrote:
> > >
> > > I am about to buy the Ashling Vitra Trace Debug tools. They are 
about
> > > half the cost of Realview tools, but is there a significant 
difference
> > > between them?
> > >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> >
>