AW: Third party compilers for ADSP family

Started by Andor Bariska September 15, 2000
> Can anyone give me typical performance comparision of for Analog
Devices >Software Tools for ADSP-218x platform.
> MIPS of a Cross compiled assembly program Vs MIPS of Optimized Hand
Written >assembly program?
>Typical example : for any ITU series Speech codecs.
>Hari V


this is a typical "it depends" question. There are many factors that
determine cycle count for any given algorithm (the MIPS rate is constant
and depends on your hardware). Using the assembly libraries from ADI,
you are likely to have very optimized code, which propably cannot be
compacted much further.

If you can compile (pun intended ;) your program exclusively from
library functions, all you have is the C overhead (handling stack and
heap, loading pointers, additional register loading and storing, C
function calling) in the main loop, but this is negligible compared to
calculating an FIR, multiple-section IIR or an FFT, especially on
today's fast DSPs.

The more complex your program gets, the larger becomes the relation
between overhead to processing. There are two main reasons for this:

1. When you program in assembler, you are used to a much leaner
programming style (eg. using several bits in one word as flags instead
of several words, using predicated instructions instead of conditional
branching, vector based programming vs. structured programming, direct
hardware drivers, etc.) as compared to higher-level programming. One
also has direct access to all registers (and for the SHARC, these are
usually enough to reserve index registers for certain tasks), and one
can organize multiple instruction computes and parallel data store /
loads, which the C compiler usually ignores completely.

2. Even when using exactly the same program structure (for example when
compiling a C program to assembler), the assembler code can _always_
easily be optimized, because a compiler is a very general function
(having to be able to compile all possible programs), and there are
always details which can be coded in way better suited for a specific
problem. So if you have to make your own code, that is, you use functions which
are not available in the pre-compiled libraries, and you are using many
loops, conditional statements, lots of arithmetic, special filter
functions, ie. you are making _complex_ code, that's when assembler
starts getting ahead of C.

Also, for these complex programs, the C code explodes in size, which
might require you to store code in external RAM segments, something I
never used in my whole career as an assembler DSP programmer (and I
believe I haved programmed some pretty wicked applications). Executing
code from external RAM (depending on RAM type) can turn your SHARC into

The points is: you _can_ program efficiently in C, if you know your
hardware (however, the same person can always generate more efficient
assembler code). The problem is, if you program in C _because_ you don't
know the hardware (hardware independency is the reason for having
higher-lever programming languages in the first place), you will usually
end up needing more and faster processors.

You have to decide which costs more: more capable hardware or the time
it takes you to get into assembler coding.
Andor Bariska

WEISS ENGINEERING LTD. - Professional Digital Audio Products
Florastrasse 42 8610 Uster Switzerland
phone: +41 1 940 20 06, fax: +41 1 940 22 14
mailto: web: http://www.weiss.ch
You *can* afford the best