Re: DSP C Compiler Question???

singhvk@eecg.toronto.edu (Vijaya Singh (Vij)) asks:
> From what I've been reading, they're a number of DSP C compilers in
> existence, but they tend to generate "poor" code. ...
> BTW: Do these compilers typically only get used for generating control
> structures, relying on hand-coded kernals to do the actual
> number-crunching???


I've done extensive work with the C Compiler for the TI TMS320C30 DSP chip
over the past year of so and it's been my experience that, in general, the
compiler takes pretty good advantage of the DSP features of the 'C30. With
full optimization turned on, delayed branches are generated instead of
regular branches (saves 4 cycles); instructions are scheduled to take
advantage of the parallelism available on the chip; and block repeats are
used instead of "increment and compare" loops. All and all, pretty good.


As to the use of the C code, I use it for number crunching in certain
cases. An FFT in assembly language with all the loops unrolled is still
certainly faster than the compiler generated code, as the compiler does
not seem to know about generating instructions to take advantage of
circular addressing, but for filtering and decimation and other cases
where circular addressing isn't an issue, I use the compiler.


The compiler for the parallel-oriented TI 'C40 is due out anytime and they
are promising compiler support for multiple data and instruction areas.
After reading the tech book on the the 'C40, I'm pretty skepticle.


Anyway: yes, there is a DSP compiler out there that takes pretty good
advantage of a DSP chip. With the single exception of the lack of support
for circular addressing, I would feel comfortable coding numerical
algorithms in C on the compiler.


Steve McDowell
mcdowell@exlog.com


--

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