Re: HLL for dsp compiler?

Grant Griffin <>
31 Aug 1998 12:17:33 -0400

          From comp.compilers

Related articles
HLL for dsp compiler? (Kent Stenman) (1998-08-30)
Re: HLL for dsp compiler? (1998-08-31)
Re: HLL for dsp compiler? (Jan Guffens) (1998-08-31)
Re: HLL for dsp compiler? (Grant Griffin) (1998-08-31)
Re: HLL for dsp compiler? (1998-08-31)
Re: HLL for dsp compiler? (Brent Kimberley) (1998-09-01)
Re: HLL for dsp compiler? (Jerry Avins) (1998-09-01)
| List of all articles for this month |

From: Grant Griffin <>
Newsgroups: comp.dsp,comp.compilers
Date: 31 Aug 1998 12:17:33 -0400
Organization: Iowegian International Corporation
References: 98-08-199 98-08-203
Keywords: DSP, design

Dwight VandenBerghe wrote:
> 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

In my experience, these little routines are mostly what DSP software
implementations _are_. Things like FFT's, FIR's, IIR's, math
functions (sine, arctangent, magnitude, log, exp), AGC, etc.

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

The _bad_ news is that you probably still need to program most of your
DSP system in assembler for speed--and maybe you always will: as
processors get faster, we all want to do more with them, so the need
to squeeze out the maximum performance remains. However, the _good_
news is that if you write good assembly routines to do the functional
blocks above, and make them as reusable as possible by emphasising the
use of assembly macros, you _will_ be able to obtain a high degree of
DSP assembly code reuse. The unique code you _can't_ reuse--the
system control code--probably is not as time critical, and can be
written in C. In my experience, this type of "hybrid" system is
almost always the most "efficient" system because it balances
processor efficiency and development efficiency.

But there's a little more bad news: Once you write a large library in
assembler, you tend to be stuck with whatever family of parts you
chose. The DSP microprocessor manufacturers are well aware of this,
which is why they have kindly provided us with large families of
completely-compatible and mostly-compatible parts. But if all the DSP
manufacturers would provide truly useful, comprehensive libraries of
assembly code (like the ones we have been writing ourselves) then it
would be a lot easier for us to switch around.



Grant R. Griffin
Iowegian International Corporation

Post a followup to this message

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