|Compiling for DSP chips email@example.com (1990-09-07)|
|Re: Compiling for DSP chips firstname.lastname@example.org (1990-09-11)|
|Re: Compiling for DSP chips email@example.com (1990-09-24)|
|Re: Compiling for DSP chips firstname.lastname@example.org (1990-09-26)|
|Re: Compiling for DSP chips seanf@sco.COM (Sean Fagan) (1990-09-30)|
|Re: Compiling for DSP chips email@example.com (1990-10-02)|
|From:||firstname.lastname@example.org (Reid Tatge)|
|Date:||Fri, 7 Sep 90 11:06:20 -0500|
Concerning the article by email@example.com (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
Concerning comments by firstname.lastname@example.org (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.
Return to the
Search the comp.compilers archives again.