Re: DSP C Compiler Question???

> From what I've been reading, they're a number of DSP C compilers
> in existence, but they tend to generate "poor" code. Since


Historically C compilers for DSP chips have been inefficient. This may be a
result of limitations in the C language rather than in the implementation of
the compilers themselves (modulo addressing for instance). Motorola's new
GNU based C compilers for the DSP56000/1 and DSP96002, however, show
considerable improvement over there predecessors.


> I don't (yet!) have access to any of these compilers, I'm curious
> as to how "poor" the results are. That is, can these compilers take
> advantage of or effectively utilize:
>
> - "do" and "rep" type instructions
YES. See attached code below.


> - "mac" type instructions
YES. See attached code below.


> - address and data register banks
YES. See attached code below.


> - "fft" and "mod" addressing modes
NO.


> - dual data memory banks
If, by dual memory, you mean dual DATA memory (the X and Y data space
of the DSP56000/1), the current Motorola compiler will not take full advantage.
The primary reason for this is due to the run-time overhead that would be
required to dynamically test pointers (i.e. does a pointer point to X or Y
data space?).


> BTW: Do these compilers typically only get used for generating
> control structures, relying on hand-coded kernels to do the actual
> number-crunching???


Typically this is the case but it would be reasonable to develop the entire
algorithm in C, then gradually replace sections with hand-packed assembly code
if necessary.


Attached is an example C program with resulting DSP56000/1 assembly code
generated by the compiler (fabulous example provided by Analog Devices).


>> int i;
>> conv = 0;
>> for(i=0;i<100;i++)
>> conv += A[i]*B[i];


on the DSP56000/1 becomes:


clr a x0,y:(r6)+
move y0,y:(r6)+
move r1,y:(r6)+
move #FA,r1
move r2,y:(r6)+
move #FB,r2
do #100,L7 ; hardware DO instruction
L5
move a,a0
asl a y:(r2)+,y0 ; <--+- auto incrementing address reg.
move y:(r1)+,x0 ; <--+
mac +x0,y0,a ; <-- MAC
asr a ; adjust for fractional
move a0,a ; arithmetic
L7




and on the DSP56156 becomes:


                clr a
                move #>Fb,r1
                move #>Fa,r0
                do #100,L7
L5
                move x:(r0)+,x0
                move x:(r1)+,y0
                imac x0,y0,a
L7


<< comp.compiler guys fade out ... >>


Putting on my marketing hat, I can say that our current set of compilers for
our complete line of DSPs perform a great deal of current optimization
techniques (both provided by the GNU source release and many things that we
have added to get "closer" to our architecture). As is the case with many
products, our compilers continue to improve - hopefully to the point of
eliminating the need for assembly language coding.


Peter Percosan
Compiler guy, Motorola DSP Group
Austin Texas
pete@chomsky.sps.mot.com
[Assuming you distribute your compilers, whom do we ask to get the source
code? -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.