|HLL for dsp compiler? firstname.lastname@example.org (Kent Stenman) (1998-08-30)|
|Re: HLL for dsp compiler? email@example.com (1998-08-31)|
|Re: HLL for dsp compiler? firstname.lastname@example.org (Jan Guffens) (1998-08-31)|
|Re: HLL for dsp compiler? email@example.com (Grant Griffin) (1998-08-31)|
|Re: HLL for dsp compiler? firstname.lastname@example.org (1998-08-31)|
|Re: HLL for dsp compiler? email@example.com (Brent Kimberley) (1998-09-01)|
|Re: HLL for dsp compiler? firstname.lastname@example.org (Jerry Avins) (1998-09-01)|
|Date:||31 Aug 1998 12:23:25 -0400|
|Organization:||Deja News - The Leader in Internet Discussion|
email@example.com (Dwight VandenBerghe) wrote:
> 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.
Do you find that you have code that is macro-like, appearing in lots
of places, but just different enough that you can't use macros for it?
I mean common idioms that need a little bit more information than a
macro has available?
If so, take a look at the Aspect Oriented Programming Home Page:
One paper there was specifically about optimizing image processing
loops. The idea, in one way, is to allow language extensions in an
environment where you can have all the info you need about a program
right there--symbol tables, the AST, etc. Many different "aspects"
can do source transformations on the input program before it is sent
to a real compiler. This is a pretty new area of research, no telling
how well it might work in practice.
Return to the
Search the comp.compilers archives again.