Thread View: comp.dsp
3 messages
3 total messages
Started by Johan Van Praet
Wed, 16 Dec 1992 14:16
compilers for DSP processors
Author: 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. |
+----------------------------------------------------------------+
Re: compilers for DSP processors
Author: C.M. Hicks
Date: Thu, 17 Dec 1992 12:46
Date: Thu, 17 Dec 1992 12:46
37 lines
2228 bytes
2228 bytes
vanpraet@imec.be (Johan Van Praet) writes: >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. >- Which method do you use to write code ? All my DSP code is 100% assembler, but I often prototype algorithms in MATLAB on a PC to get the *algorithm* right, before diving into coding for speed on the DSP. DSP assembly language is such that it is relatively easy to write good, readable code (main experience is with DSP32c and ADSP21xx). I find that a compiler really does not make coding that much easier, particularly if the assembler supports macros etc. Direct assembly language coding also allows me to use tricks with the pipeline, special addressing modes (eg bit-reversed, circular buffers), zero-overhead loops and so on, squeezing as much useful work out of the processor as possible. (Most of my work is in audio processing) DSP chips are designed to be fast, and to slow them down with compiled code seems daft, particularly in real-time applications. Obviously development time (and hence cost) is an issue, but I can write DSP code as good as any compiler, just not quite as quick...:-) Christopher-- ============================================================================== Christopher Hicks | If it doesn't fit... cmh@uk.ac.cam.eng | ...you need a bigger hammer. ============================================================================== -- ============================================================================== Christopher Hicks | If it doesn't fit... cmh@uk.ac.cam.eng | ...you need a bigger hammer. ==============================================================================
Re: compilers for DSP processors
Author: Malcolm Slaney
Date: Sat, 19 Dec 1992 16:56
Date: Sat, 19 Dec 1992 16:56
28 lines
1961 bytes
1961 bytes
cmh@eng.cam.ac.uk (C.M. Hicks) writes: >DSP chips are designed to be fast, and to slow them down with compiled code >seems daft, particularly in real-time applications. Wow, you must work for a DSP chip maker. Most DSP makers seem to be clueless about how to write software. Or maybe you have been brainwashed by the hardware makers (I don't mean this personally....I'm just tired of the idea that assembly language is necessary.) On most reasonable processors, people have found that the compilers write better code than humans do. Compilers can do a much better job of global register allocation, scheduling, and all the other things that make for good translations. This is especially true of today's RISC machines (DEC, IBM, HP, Sun, Cray, MIPS). For a good exposition of the power of a compiler, read John Ellis' book on the Bulldog compiler for VLIW machines. It is especially amusing that the C compiler for the AT&T chips is so BAD. The assembly language was designed to look like C. Analog Devices is at least trying to modify C to make it friendlier for DSP but I'm not sure that their efforts will be successful. Any high level language is better for us humans than machine code. Listen up DSP makers....compilers can write better assembly code than us mere humans.....especially if you give the compiler a chance. Pay attention to the lessons that the RISC people taught the CISC dinasours. Malcolm Slaney DSP Hacker on all sorts of machines
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads