Re: Reverse compilation of DSP code

Grant Griffin <grant.griffin@iowegian.com>
7 Feb 1999 00:14:11 -0500

          From comp.compilers

Related articles
Reverse compilation of DSP code adrian@dcs.rhbnc.ac.uk (1999-02-05)
Re: Reverse compilation of DSP code andrew@lake.com.au (1999-02-07)
Re: Reverse compilation of DSP code grant.griffin@iowegian.com (Grant Griffin) (1999-02-07)
Re: Reverse compilation of DSP code zalman@netcom.com (1999-02-07)
Re: Reverse compilation of DSP code guthseel@cesys.com (Peter Guthseel) (1999-02-10)
Re: Reverse compilation of DSP code Juergen.Kahrs@t-online.de (1999-02-10)
Re: Reverse compilation of DSP code nr@labrador.cs.virginia.edu (Norman Ramsey) (1999-02-10)
Re: Reverse compilation of DSP code m.lambertson@computer.org (Michael Lambertson) (1999-02-12)
Re: Reverse compilation of DSP code dmitrik@my-dejanews.com (1999-02-15)
[1 later articles]
| List of all articles for this month |

From: Grant Griffin <grant.griffin@iowegian.com>
Newsgroups: comp.compilers,comp.dsp,comp.compilers.tools.pccts
Date: 7 Feb 1999 00:14:11 -0500
Organization: Iowegian International Corporation
References: 99-02-021
Keywords: DSP, translator

A Johnstone wrote:
> [ looking for work in translating DSP assembler to something else ]


This sounds like a very interesting project. However, it is the first
such project I have heard of.


In the past, most DSP microprocessor programming has been done mostly
in assembly language. Until recently, C compilers for DSP
microprocessors have produced pretty inefficient code. This is
probably due mainly to two factors, 1) the size of the compiler DSP C
compiler market was very small, and, 2) the architecture of the DSP
parts was "unfriendly" to compilers--particularly the fixed-point
parts. (For example, I did an experiment a few years ago using the
Analog Devices 21XX C compiler (v3.2) which showed that it produced
code which was about 20:1 in both size and speed compared to the best
hand-coded assembly.) Therefore, DSP software developers have favored
assembly to achieve the utmost in speed and size efficiency (and many
still do). Use of assembly is made easier by the fact that DSP
software tends to be of a fairly small size, and also is fairly
reusable due to its reliance on recurring well-defined blocks such as
filters, FFT's, mixers, etc.


But more recently, as floating-point parts have become cheaper and the
overall DSP market has grown, a few high-quality DSP microprocessor
compilers have become available, making it more practical to write DSP
software in C. And as you suggest, TI tells you that you should
program their VLIW machines in C.


However, even given good DSP C compilers, my concern with any reverse
compilation of assembly into C would be that the C might be relatively
hard to maintain, and it might not be very efficient C.
(Remember--the assembly code was probably extremely
architecture-specific.) Therefore, I suspect that in terms of
life-cycle cost, a better approach might be to start with whatever
documentation of the original software exists, and simpy re-write the
whole thing in C, by hand. Such an effort would begin with writing
(or buying) a suitable library of DSP primitive blocks (which is how
one always starts whenever switching processor families.)


Unfortunately, though, this wouldn't be a very interesting project...


=g2
--
_____________________________________________________________________


Grant R. Griffin grant.griffin@iowegian.com
Iowegian International Corporation http://www.iowegian.com


Post a followup to this message

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