Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

torbenm@diku.dk (Torben AEgidius Mogensen)
5 Mar 1996 12:25:07 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? mwilliam@duncan.cs.utk.edu (1996-03-03)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? eyal@dsp.co.il (Eyal Ben-Avraham) (1996-03-03)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? jens.hansson@mailbox.swipnet.se (1996-03-03)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-04)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? andrew@memex.co.uk (Andrew Cruickshank) (1996-03-04)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? fink@post.tau.ac.il (1996-03-05)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-05)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? hatrjo@hat-fi.kone.com (Risto Jokinen) (1996-03-05)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? max@gac.edu (1996-03-06)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? rhn@sgi.com (Ron Nicholson) (1996-03-06)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? yatesc@csee.usf.edu (1996-03-06)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-07)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? thinklab@earth.usa.net (1996-03-08)
[41 later articles]
| List of all articles for this month |
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.compilers,comp.dsp
Date: 5 Mar 1996 12:25:07 -0500
Organization: Department of Computer Science, U of Copenhagen
References: 96-03-006 96-03-025
Keywords: optimize, code, DSP

"David J. Starr" <dstarr@pop-3.std.com> writes:


> DSP's are a different breed of cat. The performance in a DSP is
>gained from the use of multiple address spaces, all fetched
>simultaniously. For good DSP performance, the programmer has to be
>able to specify which arrays of data go into which memories. The
>typical multiplier accumulator needs two operands to stuff into the
>the multiplier on each cycle. Typically the DSP has a pair of data
>memories (A and B). Multiplication is quick when multiplying data in
>A by data in B, and slow (or impossible) when multiplying data in A by
>data in A. (or B by B). C just doesn't have the syntax to say "locate
>this array in the A data memory and that array in the B data memory.
>In C, memory is memory. In theory a set of #pragma's could be defined
>to specify where to put data, but these pragma's would be machine
>dependant and vary from manufacturer to manufacturer, which defeats
>the main purpose of using a high level language (portability).


This doesn't sound too difficult to solve in a compiler: whenever a
MUL between array elements happen, a constraint that the arrays should
be in different memories is generated. Once all constraints are found,
it is tested whether they can be solved, and in case they can't you
use some heuristic based on cost (similar to register spilling
heuristics) to decide where to slack the constraints. This can be done
at link time (it is anyway the linker that decides where to store
arrays).


> In practice, the tough DSP algorithms are things like FFT, FIR,
>convolution. You should be able to obtain optimized assembler code
>for this stuff and call it from C. So your main routine and much of
>the code would be C, and the key routines would be hand done assembler
>from a library supplied by the DSP chip maker.


I agree that things like the bit-reversed addressing found in some
DSPs for FFT etc. are difficult to impossible to handle in a compiler
for C. A way is to put some things into libraries, which can then be
optimized for each machine, either using assembly language or
specialized idioms that the compiler can recognize as being equivalent
to a particular machine feature. Some compilers e.g. compile the
expression (x<<(32-n))|(x>>n) to a rotate by n bits (on 32-bit
processors).


Torben Mogensen (torbenm@diku.dk)
--


Post a followup to this message

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