Article View: comp.dsp
Article #1856compilers for DSP processors
From: Johan Van Praet
Date: Wed, 16 Dec 1992 14:16
Date: Wed, 16 Dec 1992 14:16
65 lines
3902 bytes
3902 bytes
I am writing a report on different approaches to generate code for a
DSP processor and would like to hear some opinions of the net-people
about this.
As far as I know most of the code for a DSP-processor is written in
assembler 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.
On the other hand I read in an EDN issue (of 7 november 1991) that
some people do 90% of their code in C and 10% of the code in assembly
language (I think of this as an application of the 90/10 rule -- i.e.
that 90% of the execution time of a program is spent in 10% of the
code -- so that these 10% of code must be optimal).
- Which method do you use to write code ?
- Do you agree on the above ? (on the use and the quality of DSP compilers)
- What causes this factor of 5 on the code size ?
e.g. -> the input language ?
- 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 two 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)
These don't start from a procedural language (resp. from block
diagrams and from Silage) and have both some sort of library of
manually written code-pieces. They also perform some sort of global
scheduling. 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 |
+----------------------------+-----------------------------------+
|In theory, there is no difference between theory and practice. |
|But, in practice, there is. |
+----------------------------------------------------------------+
--
+----------------------------+-----------------------------------+
| Johan Van Praet | IMEC , Kapeldreef 75 |
| vanpraet@imec.be | 3001 HEVERLEE , BELGIUM |
+----------------------------+-----------------------------------+
|In theory, there is no difference between theory and practice. |
|But, in practice, there is. |
+----------------------------------------------------------------+
Technical Details
Message-ID:
<1992Dec16.141628.28304@imec.be>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!ub4b!imec.be!tiamat!vanpraetShow Full Headers
Complete Article Headers
Newsgroups: comp.dsp Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!ub4b!imec.be!tiamat!vanpraet From: vanpraet@imec.be (Johan Van Praet) Subject: compilers for DSP processors Message-ID: <1992Dec16.141628.28304@imec.be> Followup-To: comp.dsp Lines: 65 Sender: vanpraet@tiamat (Johan Van Praet) Nntp-Posting-Host: tiamat Reply-To: vanpraet@imec.be (Johan Van Praet) Organization: Imec Date: Wed, 16 Dec 1992 14:16:28 GMT