Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!husc6!spdcc!ima!esegue!compilers-sender From: tatge@m2.csc.ti.com (Reid Tatge) Newsgroups: comp.compilers Subject: Compiling for DSP chips Keywords: DSP, code Message-ID: <9009071606.AA22759@m2.csc.ti.com> Date: 7 Sep 90 16:06:20 GMT Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: tatge@m2.csc.ti.com (Reid Tatge) Organization: Compilers Central Lines: 47 Approved: compilers@esegue.segue.boston.ma.us Concerning the article by tommyp@isy.liu.se (Tommy Pedersen) in which the moderator wrote: > People I know in the DSP bix tell me that although there are many C > compilers for DSP chips, nobody uses them because they're all too slow. I've spent the last few years writing compilers for our (TI's) DSP chips, so I thought I should respond to this. There are really two classes of DSP chips on the market today : fixed-point and floating point. The TMS320C25 is fixed point, so I'll talk about that first. In general, the DSP fixed-point processors across the industry are "compiler-hostile", or in other words, very difficult to map general purpose HLL's onto. The `C25 is an accumulator machine with no offset addressing and very little support for arbitrary address arithmetic. Consequently, compilers tend to generate sequences of instructions which would translate to single instructions on any more conventional CPU. Why such an apparently contorted ISA? The reason is simple: DSP fixed-point processors are designed to optimize price/performance for DSP algorithms, often at the expense of general purpose performance. They are targeted at real-time applications where the time-critical kernels are very small and arithmetically intensive. Most DSP folks are more than happy to code these in assembly. However, this is changing - algorithms are becoming increasingly complex, and the need for high quality compilers cannot be discounted. Concerning comments by mhorne@ka7axd.wv.tek.com (Mike Horne) > Generally speaking, few people use compilers to generate code for DSP chips > for *time critical* code sections. Note that this includes just about all > signal processing algorithms. However, you can use a high-level language > (such as C) to build the *structure* of the program and use in-line assembly > for time critical sections..... I agree. This is generally an excellent approach. However, by applying more sophisticated optimization strategies, we plan to narrow the gap between hand coded assembly and C performance. This is particularly true in the floating-point CPU arena (TMS3203x). The new generation of floating point DSP's tend to be moving towards more conventional compiler-friendly architectures. As the compilers become more sophisticated, they enable people to code their entire program in C, with very little, if any, performance penalty (with all the obvious benefits). Over time, the improved technology will also be applied the fixed point processors. Reid Tatge -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.