Compiling for DSP chips

tatge@m2.csc.ti.com (Reid Tatge)
Fri, 7 Sep 90 11:06:20 -0500

          From comp.compilers

Related articles
Compiling for DSP chips tatge@m2.csc.ti.com (1990-09-07)
Re: Compiling for DSP chips kuusama@news.funet.fi.tut.fi (1990-09-11)
Re: Compiling for DSP chips avi@taux01.nsc.com (1990-09-24)
Re: Compiling for DSP chips pardo@cs.washington.edu (1990-09-26)
Re: Compiling for DSP chips seanf@sco.COM (Sean Fagan) (1990-09-30)
Re: Compiling for DSP chips pardo@cs.washington.edu (1990-10-02)
| List of all articles for this month |

Newsgroups: comp.compilers
From: tatge@m2.csc.ti.com (Reid Tatge)
Keywords: DSP, code
Organization: Compilers Central
Date: Fri, 7 Sep 90 11:06:20 -0500

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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.