Re: Reverse compilation of DSP code

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

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