Blackfin two-word *fast* floating-point library

Andor wrote:
> 
> Jerry Avins wrote:
> ...
> > > There are many criteria by which to measure code quality: execution
> > > speed, memory requirement, upgradeability, modifiability,
> > > reuasability, development speed, portability, etc.
> ...
> > I'd like to see, or hear of anecdotally, an optimal embedded system
> > written in complete ignorance of the hardware it is to run on.
> 
> Jerry,
> 
> you did not read what I wrote. An optimal software solution needn't
> neccessarily be the most efficiently running code. There can be other
> criteria by which to measure quality. I've given a few above.
> 
> Regards,
> Andor

Andor,

I guess I didn't express myself clearly. Even by the criterion of speed,
often the first code to give an answer won't be the code that runs most
quickly. My claim was that your claim didn't fit embedded apps. It's
rare embedded code that runs only once, and the few examples I can think
of (cruise-missle guidance, e.g.) need to make full use of processing
resources.

Note that I didn't write, or mean to imply, that faster is necessarily
better. (I wrote professional code in indirect-threaded Forth to
optimize maintainability, code size, and writing time, even though
assembly was more than twice as fast.*) The example I asked for was
useful embedded code, optimal by any standard, written in complete
ignorance of the hardware it runs on. I expect that there is no example,
but I hope I'm wrong. It would be a wonder to see.

Jerry.

P.S. The quote I claim doesn't apply to embedded work is, "Thus, you can
produce optimal code and be completely ignorant of the hardware it runs
on."
_____________________________
* Optimized native-code Forths run about as fast as Gnu C, give or take
ten percent, depending on the application and the programmer's skill.
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������