Gene Frantz
TI Principal Fellow, Futurist and Business Development Manager, DSP

When we began the era of Digital Signal Processors in the early 1980s, they were programmed using assembly code.  As the technology matured we began to move to using a high level language to program the processors.  At first it was seen as a quick start to the solution before the real work began using assembly code.  We are now far beyond the point of resorting to assembly code to make the processor “sing”.

Why has this happened?  I suggest for several reasons:

- IC technology has advanced to the point where we can be sloppy.  We don’t need to maximize the use of the raw performance we now get in an embedded processor.

- Embedded processors in the old days were the domain of hardware designers, usually Electrical Engineers who were comfortable in writing code specifically directed at the processor architecture.  Now, embedded processors have been made available to everyone – EEs, CS’s, ME’s, CE’s etc.  While this has expanded the user base of embedded processors from tens of thousands to millions.  With this expansion we have lost the art of assembly code.

- Systems have gone from needing several thousand lines of code to millions of lines of code.  This growth in code size has driven us to emphasizing reuse and discipline that a high level language brings to the party.

- The cost of being sloppy has gone down significantly allowing for all of the movement possible.  It is somewhat humorous that it has been power dissipation, as  much as any other aspect, that has awakened us to the issues of being sloppy.

So, we took on a new approach to solve the problem - optimization.  OK, so it isn’t new, but then, it doesn’t really work that well either.  But not all hope is lost.

It is possible to get most of the raw performance out of a processor, even writing in a high level language.  But I’ll leave the details up to a friend of mine, Reid Tatge.  Reid is our senior technologist at TI in the area of high level language tool development.  He recently spent several weeks of his time sitting with engineers at our customers who have been writing C code on our Embedded Processors.  His request to them was for them to bring him their code for him to look at and see if it could be further optimized.  He found many cases where, with his expertise and knowledge of the processor’s architecture, he could increase the performance of critical loops anywhere from 50% improvement to 40 times improvement.  These improvements were beyond the optimizations done by the compiler without human intervention.

I have invited him to write a series of blogs giving specific hints on how to improve the real performance of software running on an Embedded Processor.  But he has turned me down.  I’ll still work at getting him to document what he has learned – I don’t give up easily.

And, before you ask, no, don’t send in your code for Reid to optimize for you.  He isn’t for hire.  He spent the time with customers to learn how to better optimize code with our C Compilers.