Re: HLL for dsp compiler?

On 30 Aug 1998 10:19:53 -0400, Kent Stenman
<kent.stenman@emw.ericsson.se> wrote:
>My question is which language is the best front-end language for dsp
>compilers?


This is a tough call, Kent. There are a number of problems with
current languages and DSPs - having separate address spaces (like A nd
B for the Motorola chips), having extremely fast and tight
instructions that are designed to be used in specific ways, like the
multiply-and-adds that overlap, and the special REPEAT instructions
that do the next single instruction a given number of times using only
one cycle each. These are not things that can be easily seen or
optimized by a compiler for FORTRAN or C or Pascal or Limbo or Ada.


I've been thinking about the problem for a while, with the intention
of writing a DSP compiler that would out-perform the current offerings
(Archelon, etc). I think the solution is to design a new, C-like
language that caters to the anomalies of the DSP world. I'm working
on it. Are you? Should we talk?


>[I'd choose whatever language already has the most code you plan to
>reuse. Also, remember that compilers with multiple front ends are
>now common, and even lacking that, you can use f2c to turn
>computational Fortran into C. -John]


I'd have to disagree, John. You don't tend to reuse all that much
code in the DSP world, except for little assembly-language subroutines
for things like FFTs and wavelet transforms and so on. You do look up
algorithms, for example in Numerical Recipes, but then you recode them
in assembler. You live and die by the speed of your application - DSP
programmers will kill for speed. You use C to wrap things together,
but you're always thinking about how the underlying code is being
generated, much more so than in normal programming. The reason, I
think, is that you are the critical path in the middle of a processing
pipeline. You have read in the data from 2048 samples of a waveform
from the A-to-D converter, and you have exactly X microseconds to find
the bump in the curve and smooth it out before the alarm clock goes
off and you have to shove it out the DAC and go get some more data.
It's like writing a UART driver - you gotta be done and ready for more
data, or you lose bits. So there's not a lot of concern about porting
old FORTRAN programs to the DSP, at least, not in the DSP projects
I've been associated with. There's a lot of concern about getting the
MATLAB simulations to match the real world, and then in coding up the
MATLAB program into the DSP and getting it to run fast enough to keep
up with the data pipeline.


So IMHO the language problem in DSP land is that there is no good
language for DSPs as yet. The beginners, and those whose applications
aren't that time-critical, use the C tools. The rest of the land,
including most of the real pros, use assembler.


Dwight
[Oh, right. The last time I thought about DSPs, back when the 56K was
hot stuff, I pondered schemes that would more or less compose prewritten
chunks of code. It was more a way to specify digital filters at a higher
but relatively general level than a full programming language. -John]




--

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