To Bill (WL) Boulton:

I'm not going to ask my employers to hire such a person.
My primary purpose is to put bread on my table,
not myself on the dole. :-)

I'm sure they'd have preferred a really experienced person,
but in the real world companies have to get the best they
can at reasonable notice and cost.

Better programming skills producing better algorithms
are always desirable, but note this problem is not a
typical university course problem.

I'm aware that an algorithm may vastly improve execution
times: e.g. Bubblesort vs. Quicksort.
Sorting a list of items is a single conceptually simple task.

In embedded control systems, or at least in mine,
there are not one but many tasks being done.
The single most important aspect is not execution speed.
It is robustness and reliability.
The main difficulty is not finding a better algorithm.
It is keeping track of all the possible interactions,
use of resources, etc.
This is a tedious task I'm sure even the most gifted
programmer would gladly abdicate to a computer.

I have tried to use as many ways as I can to automate
code generation, and make it easier to specify.
Macros, cblock, etc. Thanks to Harold Hallikainen for
his thought BTW.

In reply to the slightly sarcastic :-) Wim E. van Bemmel,
I would prefer a high-level language of course, but
assembler was forced upon me! I had a look at the
code output of the CCS compiler mentioned by Mike Watson,
and appreciated the ability to generate a calling tree.
It may do many other useful things to manage the code, but
the code looked very inefficient. And it hogged code space.
In my case it doubled the size of my assembly code!

I did manage to cajole it into much smaller code size,
but was not impressed at its ability to conserve code size.
I think the best bet may be to write in C, but bear in mind
assembly techniques. This gives the compiler a nudge toward
generating smaller code.

a good rule of


Mike Harrison's comments were more what I was thinking of
when I made my posting.