In this paper we present an approach for performing dynamic context-dependent transformations (DCDT) to improve code generation for programmable digital signal processors. Unlike static optimizations, DCDT can guarantee to improve the quality of the generated code, at the expense of longer computational time. For many embedded DSP applications, hand coding in assembly is still the only effective approach. We show that our code generation approach, when combined with DCDT, can yield code of quality comparable to that of hand-written codes by DSP experts and many times superior to that generated by a conventional optimizing compiler.
INTRODUC'lrIONHigh level languages (HLLs) are attractive to programmers because they simplify the task of programming. Unlike assembly codes, HLL programs are readable, maintainable and portable to other processors. These features contribute to increase productivity and reduce development cost.A HLL compileir translates the instructions present in a HLL program into assembly instructions, more easily understood by the processor. HLL compilers for programmable digital signal processors (PDSPs) have existed for several years [ 11. Unfortunately, the performance of commercially available compilers for PDSPs is acceptable only to a few non-critical applications [2]. For embedded DSP applications with stringent constraints on execution time and code size, careful manual coding, typically with several fine-tuning iterations, is still the only effective approach.A typical compiler can be viewed as a front end (FE) feeding a back end (BE). The FE translates the input HLL program into an intermediate representation (IR). The BE translates the IF: into the output assembly code. The mapping of HLL instructions to IR operators is processor independent and is well defined using models such as contextfree grammar [3]; many tools exist to automate that task. In contrast, the maipping of IR operators to assembly instructions, also known as code generation, is highly machine dependent and leaves much room for ad hoc approaches.Even if a BE could generate optimal code for a given IR, that code may still be inferior to hand-written assembly code. The reason is simple. Although the IR can uniquely represent a given sequence of HLL instructions (program), the latter is not a unique implementation of a desired algorithm. In fact, there are infinite programs that evaluate a given expression. For example, ( a x b ) could also be implemented as [(a + b)2 -a2 -b2] 1 2 .The use of HLLs emphasizes the issue of algorithm transformation. Unlike assembly languages, HLLs are, in principle, processor-independent. Without target architecture information, HLL programmers cannot bias the program towards certain constructs, as experienced assembly programmers often do. Hence, it is the responsibility of the compiler to perform such transformations.In static transformations the compiler uses static analysis to determine the merits of a transformation. For instance, the apparently more complex implementation) may actually m...