From: | Ron Nicholson <rhn@sgi.com> |
Newsgroups: | comp.compilers,comp.dsp |
Date: | 6 Mar 1996 21:13:29 -0500 |
Organization: | Silicon Graphics, Inc. |
References: | 96-03-006 96-03-025 96-03-040 |
Keywords: | optimize, DSP |
"David J. Starr" <dstarr@pop-3.std.com> writes:
>... DSP's are a different breed of cat. The performance in a DSP
>is gained from the use of multiple address spaces, all fetched
>simultaniously. For good DSP performance, the programmer has to
>be able to specify which arrays of data go into which memories.
Torben AEgidius Mogensen wrote:
> This doesn't sound too difficult to solve in a compiler: whenever
> a MUL between array elements happen, a constraint that the arrays
> should be in different memories is generated.
Unfortunately, the dynamic characteristics of the algorithm is lost.
A compiler like this would optimize based on static analysis, which
may be exactly the wrong thing.
- HLL's help programmers write larger programs in a given time. DSP
programs tend to be short.
- HLL's tend to be limited to standard portable data types. Many
DSP's use non-standard data types and operators to enhance perfomance
and reduce code size.
- While it's possible to write a compiler that would produce any given
code sequence, it's much harder to verify that the compiler is still
correct than it is to verify that the code sequence works for it's one
specific intended application.
- DSP's tend to go in high volume non-reusable applications. The cost
per byte of ROM may be much larger than the cost per line of code.
---
Ron Nicholson mailto:rhn@sgi.com http://www.nicholson.com/rhn/
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.