[sdiy] Re: 1970's again? Now DSP assembly
Kenneth Elhardt
elhardt at worldnet.att.net
Mon Jan 31 09:07:53 CET 2005
Paul Maddox writes:
>>Yep, I'm on that list, and probably a good 75% of it is far above my head
(math wise). of the remaineder, most of it I understand, but has no interest
to me.
A lot of the work that seems to be done on there is done in C or C++, very
little seems to be done in DSP assembly language.
The archives are great, but its all C or C++, no DSP assembly and
translating the code into DSP assembly, isn't much fun.<<
If you go to DSP manufacturer's websites such as Motorola, Texas
Instruments, Analog Devices, you can find lots of assembly code for doing
many things.
Scott Gravenhorst writes:
>>Wow, I'm a C programmer. I can also do assembly, however, quite often C
produces the same machine language sequences as would be written for many
things, loop structure and control structures for example. Assembly comes
in
handy when logic tricks which don't translate well are used. Years ago, I
used a C compiler (QuickC 2.5, still have it) for PC (DOS) and it had a
feature called in-line assembly. One could write hybrid programs where
sections were in C and other sections were in assembly. Do DSP compilers
support this or is it a one or the other deal?<<
If you need to do that on a PC these days, Microsoft C (PC), Metrowerks C
(Mac) do it. I believe most DSP C compilers separate the two. For one
thing, the assembler is usually provided free by the DSP manufacturer while
the C compiler is something you need to buy and is written by another
company. You should still be able to write functions in assembly and call
them from C, so it's not really any big deal if it doesn't support inline
assembly.
And everytime I hear that C produces the same code or runs just about as
fast as assembly, I want to scream. I am constantly horrified by how
inefficient some C generated code is. Take this simple FIR filter line I
wrote in C:
for(k=0;k<=510;k++) ftemp+=(fir[k]*(float)*s++);
No amount of loop unrolling or indexing arrays with pointers could improve
the speed (they made it slower). A simple re-write in assembly and it runs
3.3 times faster. Granted, it's Intel's Pentium architecture, the worlds
worst and most archiac piece is sh*t 32 bit CPU ever. But anything that
needs to be done thousands or millions of times a second should always be
done in assembly. Plus as you point out, C isn't good at all those logic
tricks, bitfield operations, vector processing, and so forth.
-Elhardt
More information about the Synth-diy
mailing list