Re: DSP C Compiler Question??? (Pete Percosan)
Wed, 2 Oct 1991 21:00:33 GMT

          From comp.compilers

Related articles
DSP C Compiler Question??? (Vijaya Singh (Vij)) (1991-10-01)
Re: DSP C Compiler Question??? (1991-10-02)
Re: DSP C Compiler Question??? (1991-10-03)
Re: DSP C Compiler Question??? (1991-10-06)
| List of all articles for this month |

Newsgroups: comp.dsp,comp.compilers
From: (Pete Percosan)
Keywords: DSP, C, question
Organization: Motorola Inc., Austin, Texas
References: 91-10-007
Date: Wed, 2 Oct 1991 21:00:33 GMT

> 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

> - 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
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

and on the DSP56156 becomes:

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

<< 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
[Assuming you distribute your compilers, whom do we ask to get the source
code? -John]

Post a followup to this message

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