[sdiy] DSP coding (was: how you got started with your current µC? (was: Re: Most common ICs))

[Andrew Simper]

A good compromise between the portability of c but still having access
to specific assembler instructions is using intrinsics, but you're at
the mercy of the compiler when it comes to how optimally these
generate assembler. My usual approach is to use #defines to wrap up
the intrinsics with standard names (so I can compile the same code for
different target architectures as much as possible), and then check
the generated assembler for anything stupid the compiler is doing.

Andy

On 26 September 2015 at 18:18, Richie Burnett
<rburnett at richieburnett.co.uk> wrote:
>> A lot depends on the DSP you are using. If you are using a higher end DSP
>> that has pipe lines and multiple ALUs then using the C compiler will get
>> you
>> the best performance unless you're some sort of uber programmer. There are
>> way too many things going on in those processors to keep track of and the
>> compilers have been optimized to handle that stuff. But for the smaller
>> DSPs
>> like the MicroChip ones assembly language is the way to go if you really
>> want the performance.
>>
>> Jay S.
>
>
> Just reading Jay and Brian's comments here and I totally agree.  A fellow
> DSP programmer once told me that the key to good DSP performance is ensuring
> that the "processing pipelines are being continuously pumped".  Basically if
> a MAC unit is sat there doing nothing for a significant amount of time, then
> that is wasted resource.  On something like a dsPIC platform there is only a
> single MAC unit, and it's not pipelined, so it's fairly easy to code in
> assembly so that the MAC unit always has data and is kept busy most of the
> time, so you get good performance.  However, as Jay said, higher end DSPs
> have multiple MAC units, or multiple whole DSP cores, deep pipelining,
> additional dedicated filtering and sample-rate converter modules, etc.  It
> is much harder to keep track of all of this stuff in your head as a
> programmer, and to make sure all of the modules are kept pumped with data,
> so it's best to use a dedicated compiler that's been written to sort this
> stuff out.
>
> FWIW, I got into DSP programming about 20 years ago through my day job
> writing embedded software for instrumentation and measurement applications.
> (Most recent work project is summarised in the research paper "Electronic
> Detection Strategies for a MEMS-Based Biosensor".)  Started messing about
> with audio DSP using an Analog Devices EZ-kit lite (ADSP2181) board around
> the same time that Propellerhead software brought out Rebirth!
>
> -Richie,
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy