Lpc2000

> From: "brendanmurphy37" <brendan.murphy@...>

> > Where I will code a complete routine is for something like the 
> > TCP/IP checksum, where a hand-coded assembly routine will beat 
> > the pants off the output of most compilers.
> 
> I'd be careful about making this argument. We do a lot of DSP stuff 
> on RISC processors (digital filters of various types). For the low-
> level stuff, our starting point is a 'C' implementation. On a couple 
> of platforms we coded these up in assembler. However, we stopped 
> doing this, as by measuring the performance of the optimised 'C' 
> version we found there was little difference in performance: 
> certainly not enough to justify the additional development and test 
> time required.

In general, I agree, but the gains on an ARM were irresistible 
and we did the comparisons some years ago.

> The greatest performance gains came from algorithm 
> optimisation rather than coding in assembler.

No argument there - complete agreement.
 
> > For an ARM7, each call/ret pair costs at least six cycles. For 
> > matched entry/exit routines, that costs at least 12 additional 
> > clocks. On the LPC2xxx there are four potential MAM stalls.
> 
> Someone presented this argument in relation to coding a context 
> switching implementation. I'd argue that if you can't afford a few 
> extra cycles in your context switches, you're doing too many of them. 
> Try another approach.

Remember that MPE sells Forth compilers with an RTOS and 
drivers. We have clients who (some years ago) thought that it 
was reasonable to run interrupts at 1Mhz on a 10Mhz CPU - we've 
just learned over the years that spending a couple of hours 
reducing interrupt latency during development can save days 
later.

For most applications your arguments are valid, but 10% of 
clients cost 90% of tech support.

> > When you have an effectively 12MHz ARM (not an LPC2xxx), 
> > thirteen tasks, and a bomb-disposal machine to control, you 
> > learn to be paranoid!
> 
> I'd argue that this would lead one to maximise quality rather than 
> speed of code. Simplicity, ease of maintenance, absence of side-
> effects, portability all tend to drive quality up. Squeezing the last 
> drop of performance, using non-standard compiler extensions and the 
> like all tend to drive it down.

Define quality. The first requirement is to meet the spec! That 
job took 100 hour weeks and *all* code was documented.

My example was from a low-level device driver, not from 
application code. Now have a go at Paul's non-standard 
intrinsics :-}

Now let's agree just to disagree on some points.

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads