compilers for DSP processors

vanpraet@imec.be
Mon, 21 Dec 1992 11:18:33 GMT

          From comp.compilers

Related articles
compilers for DSP processors vanpraet@imec.be (1992-12-21)
Re: compilers for DSP processors jeff@dsp.sps.mot.com (1992-12-22)
High Quality DSP Compilers syiek@tartan.com (1993-01-04)
| List of all articles for this month |

Newsgroups: comp.compilers
From: vanpraet@imec.be
Organization: Compilers Central
Date: Mon, 21 Dec 1992 11:18:33 GMT
Keywords: DSP, question

This article was already posted (in a different form) on comp.dsp but it
only triggered a few interesting answers. Maybe comp.compilers can give
additional input.


As far as I know most of the code for a DSP-processor is written in
assembly language because either there is no suitable compiler available
or the compiled code is not good enough. Code generated by a C-compiler
for a commercial DSP-processor would be about 5 times as big as the same
algorithm manually coded in assembler. This is a generalization that can
offend some of you but I heard this from various sides, even from some DSP
processor manufacturers. Although the manufacturers also said that it will
be better in the future, as new DSP processors are designed with compilers
for High Level Languages in mind.


- Do you agree on the above ? (the quality of DSP compilers)
- What causes this factor of 5 on the code size ?
      e.g. -> The instruction set of a DSP processor does not lend itself
       to conventonal compiling techniques ?
                -> the High Level Languages are not useful for DSP?
                        - not enough parallelism in C (too difficult to extract the
                            parallelism)?
                        - too many possible constructs in C ? (a subset of C is better)
                        - non-procedural languages as e.g. Silage are better ?
                -> no global ordering and scheduling of the generated code ?
                -> no possibility of using all the provided tricks for the DSP
                      processors ?
                        - no or not enough use of the low-overhead-loop facility of a
                            processor as the "DO" for Motorola and the "RPT" for Texas
                            Instruments processors ?
                        - no use of special addressing ? (e.g. in circular buffers)
                        - no use of special block data moves ?
                        ...
                  ...


I also know of three code generation approaches that would generate more
optimal code : - The GABRIEL (PTOLEMY) system of prof. Lee at Berkeley
                                  (mainly targeted towards the Motorola 56k)
                              - The code generator for Texas Instruments' TMS320C30 in the
                                  DSP-station of EDC (in Belgium)
                              - The SPW (Signal Processing Workstation) by Comdisco, Inc.


These don't start from a procedural language (resp. from block diagrams or
from Silage) and have some sort of library of manually written
code-pieces. They also perform some sort of global scheduling and
optimization. Anyone used these ? What is their quality on real life
examples ?


You can reply by email or post a follow-up (don't include this whole thing
!). If I get significant answers, a summary will be posted.
--
Johan Van Praet | IMEC , Kapeldreef 75
vanpraet@imec.be | 3001 HEVERLEE , BELGIUM
--


Post a followup to this message

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