Lpc2000

Stephen,

First off, thanks for engaging seriously with the points I raised, 
rather than simply disparaging or insulting those with a different 
view. Having said that, I think we probably agree far more than we 
disagree. 

See some detailed comments below.

Regards
Brendan

--- In lpc2000@yahoogroups.com, "Stephen Pelc" <stephen@...> wrote:
> In general, I agree, but the gains on an ARM were irresistible 
> and we did the comparisons some years ago.

In that case, we agree 100%, if what you're saying is: "do the 
comparisons, then decide assembler or 'C'". We use the following 
strategy for time-critical systems: (1) find out where the system 
really spends its time (2) focus on the algorithms used in those 
sections and modify as appropriate (3) code in assembler (if 
necessary) and (4) most importantly: measure. The fact that we came 
up with a different result at stage (4) is kind of irrelevant: the 
point is that we both used comparative results to come to a reasoned 
conclusion. 

Note that you can stop at stage (2) if the system meets its spec at 
that stage, and save yourself a lot of development and support time 
and effort.

A minor point is that in the example I used of the digital filter 
stuff, the low-level functions were deliberately written to give the 
compiler the easiest possible job of optimisation. Sure enough, it 
spat out the appropriate series of "mac" instructions, one after the 
other as planned. The algorithm optimisation (which involved a 
technique of loop unrolling) was done at a higher level to make this 
possible.

> 
> > The greatest performance gains came from algorithm 
> > optimisation rather than coding in assembler.
> 
> No argument there - complete agreement.
>  

Nothing more to be said here.

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

I take your point. A related one I guess is that in your case you 
will be judged amongst other things on benchmark results. So for 
example a commercial RTOS might be judged on speed of context 
switch. Another case of where benchmarks are frequently misleading 
or irrelevant.

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

A useful definition of quality: "absence of defects". Meeting the 
spec is a given. After that anything that aids maintenance and 
ongoing support will tend to drive quality up. I'm talking 
generalities here: I'm sure your system was of the highest quality!

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

I'd rather see non-standard intrinsics than in-line assembler!

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

As I said, I suspect we agree far more than disagree. The only real 
difference is that in our respective toolchests, in-line assembler 
is likely to be found in a different place (somewhere near the 
bottom in mine). I wouldn't fall out with anyone because of that: 
the important thing is to be conscious of all the relevant factors 
involved in using a particular tool, and to learn from other's 
experience rather than simply blindly challange it.

Brendan