|compiler for asynchronous DSP core firstname.lastname@example.org (Lizzie Ni) (2002-07-31)|
|Re: compiler for asynchronous DSP core email@example.com (Mike Rosing) (2002-08-04)|
|Re: compiler for asynchronous DSP core firstname.lastname@example.org (Lizzie Ni) (2002-08-23)|
|Re: compiler for asynchronous DSP core email@example.com (Mike Rosing) (2002-08-24)|
|From:||"Mike Rosing" <firstname.lastname@example.org>|
|Date:||4 Aug 2002 11:40:39 -0400|
|Organization:||University of Wisconsin, Madison|
|Posted-Date:||04 Aug 2002 11:40:39 EDT|
Lizzie Ni wrote:
> Hi all
> I am wondering whether there is some difference when we construct a
> compiler between an asynchronous DSP and a synchornous DSP core? Is
> there any main thing that we need concern on writing a compiler for an
> asynchronous DSP core?
> Respect any reponse.
> [I wouldn't think so. Some of the optimization heuristics might be
> a little different, but the major issues that affect a compiler are
> data representation, word size, and addressing. -John]
One of the important things with DSP is consistent timing. As long as
your asyncrhonous result is faster than the time constraints, you
don't need further optimizations. So an important input parameter is
sample rate, and you may want to put a limit on the fraction of sample
rate any particular task is allowed. If the compiled version doesn't
meet the spec, you have reason to try further optimization, and if it
does you can quit.
The next level up would be to specify a time constraint on the entire
process, and to be sure your resulting code meets the maximum limit.
You might be able to trade off some "slow" section which doesn't meet
it's spec with another one that came out faster and have the whole
thing be within spec. It's up to the humans to accept or reject the
result at that point (the user should re-spec the lower level
Patience, persistence, truth,
www.beastrider.com BeastRider, LLC
SHARC debug tools
Return to the
Search the comp.compilers archives again.