THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

TWENTY YEARS AGO, TODAY

by Tom Cantrell

Start ý Big Bang DSP ý Compiler is King? ý Once More, With Feeling ý Sources and PDF

COMPILER IS KING?

When it comes to VLIW, the basic premise is to replace, or at least assist, the superscalar hardware that attempts to maximize parallelism at runtime with software generated at compile time. Yes, a good compiler is always importantýfor a VLIW, itýs everything.

Thereýs no better way to get a compiler working than to try some real code. To that end, the StarCore folks bit the bullet and ported an actual applicationýa GSM EFR (enhanced full rate) Vocoder that compresses/decompresses high-quality speech to 12.2 KBps.[2] As an international standard, C source code and validation suites are available, making a good test case for the compiler.

As shown in Figure 4, the compiler has been making steady progress through the current beta V.1.0 with projections of nearly a 50% overall speedup by the time the V.1.0 is released, which is expected in June.

Figure 4ýThe StarCore compiler is improving, allowing the chip to meet or even exceed the performance of ASM on midrange DSPs. But, the 2ý advantage of SC140 ASM over SC140 C puts lie to claims that C is a panacea.

Figure 4 also makes some other interesting points. One being that the combination of the SC140 and C achieves the performance of optimized assembly code on mere mortal DSPs. However, donýt make the mistake of interpreting this to mean assembly language is dead. Indeed, as the figure shows, comparing apples to apples, a hand-tuned assembly language version of the vocoder running on the SC140 is fully twice as fast as the C version.

The StarCore team decided to explore this phenomenon. After all, much of the marketing behind big-ticket DSPs alleges that ASM is history. It would be helpful (but, not absolutely necessary) if the facts of the matter didnýt prove otherwise.

First, the code was modified to allow the encoder and decoder to run separately and each to handle multiple channels. After the modified code was tested on a workstation, it became the baseline StarCore compiler benchmark.

The team identified two approaches to optimization. The most common is to follow the 80/20 rule and hand code assembly language for the 20% of inner loops that execute 80% of the time and use C for control code that consumes most of the bytes but few of the cycles.

The other approach, which they call structured C, involves modifying the source in ways that allow the compiler to generate better code. Theoretically, this is ideal because it achieves performance without sacrificing portability. However, the resulting source can become hard to read and maintain, defeating the goal of using a high-level language in the first place.

Although, a few source-level transformations were made to fully exploit the parallelism in the architecture, the team mainly relied on ASM optimization. The results, shown in Figure 5, are quite illuminating.

Figure 5ýAccording to Motorolaýs experience with an actual application (GSM EFR Vocoder), unless youýre willing to leave half your performance on the table, some DSP code (fortunately, not a lot) must be written in assembly language.

Bottom line and timeless truism: A little ASM goes a long way!

Circuit Cellar provides up-to-date information for engineers. Visit www.circuitcellar.com for more information and additional articles.
For subscription information, call (860) 875-2199, subscribe@circuitcellar.com or subscribe online. ýCircuit Cellar, the Magazine for Computer Applications. Posted with permission.