What to make out of the fixed point C code ?

Started by rootpowers July 24, 2007
I am new to this group and am looking for an answer for the following,
hope somebody can help.

How should the fixed point C code available from standard bodies like
ITU, ETSI be used. Is the reason one of the following or anything more
to it ?

(a) Use the fixed point C code only as a reference to do a *complete*
assembly level implementation on a fixed point DSP? I say this because
the fixed point C code is written in a fashion close to a DSP language
having ADD, SUB or MAC routines etc.

(b) Use the fixed-point C code and cross-compile using compile tools
from TI or Analog devices to generate assembly code.

Of the two options above 'a' or 'b', which yields the best results to
date and what is actuallt done in reality by commercial DSP based
companies that implement various codecs.

Thanks.

On Jul 24, 1:49 pm, rootpowers <rootpow...@gmail.com> wrote:
> I am new to this group and am looking for an answer for the following, > hope somebody can help. > > How should the fixed point C code available from standard bodies like > ITU, ETSI be used. Is the reason one of the following or anything more > to it ? > > (a) Use the fixed point C code only as a reference to do a *complete* > assembly level implementation on a fixed point DSP? I say this because > the fixed point C code is written in a fashion close to a DSP language > having ADD, SUB or MAC routines etc. > > (b) Use the fixed-point C code and cross-compile using compile tools > from TI or Analog devices to generate assembly code. > > Of the two options above 'a' or 'b', which yields the best results to > date and what is actuallt done in reality by commercial DSP based > companies that implement various codecs. > > Thanks.
Coding DSP projects in 100% assembly made sense in the old days of small program RAM and no hardware stack pointer -- think AD2105. I would not go back to that. I think a third option may be more common than the two you gave: (c) Use C code that calls hand written assembly language functions to do fixed point math operations on a block of numbers at a time. John
On Jul 25, 1:59 am, John <sampson...@gmail.com> wrote:
> On Jul 24, 1:49 pm, rootpowers <rootpow...@gmail.com> wrote: > > > > > I am new to this group and am looking for an answer for the following, > > hope somebody can help. > > > How should the fixed point C code available from standard bodies like > > ITU, ETSI be used. Is the reason one of the following or anything more > > to it ? > > > (a) Use the fixed point C code only as a reference to do a *complete* > > assembly level implementation on a fixed point DSP? I say this because > > the fixed point C code is written in a fashion close to a DSP language > > having ADD, SUB or MAC routines etc. > > > (b) Use the fixed-point C code and cross-compile using compile tools > > from TI or Analog devices to generate assembly code. > > > Of the two options above 'a' or 'b', which yields the best results to > > date and what is actuallt done in reality by commercial DSP based > > companies that implement various codecs. > > > Thanks. > > Coding DSP projects in 100% assembly made sense in the old days of > small program RAM and no hardware stack pointer -- think AD2105. I > would not go back to that. I think a third option may be more common > than the two you gave: > > (c) Use C code that calls hand written assembly language functions to > do fixed point math operations on a block of numbers at a time. > > John
John, Thanks for your response. From what you are saying - the best implementation would be to use C code as a kind of "shell" program that internally calls hand written assembly to do all the math, sounds right. In that scenario, the cross compile tools would be useful, to generate the final assembly and to push it on to the DSP, right ? How would the end product fare in comparison to the above method, if the cross compile tools availabe today were to be used directly on the fixed point C code itself and generate assembly code ? Will the method mentioned first be far far superior to this method or just have a marginal improvement ? The reason why this question comes is, from the availabe standard fixed point code and the available DSP compile tools I want to understand the best or most efficient possible implementation suitable for real time.
> > How would the end product fare in comparison to the above method, if > the cross compile tools availabe today were to be used directly on the > fixed point C code itself and generate assembly code ? Will the > method mentioned first be far far superior to this method or just have > a marginal improvement ? > > The reason why this question comes is, from the availabe standard > fixed point code and the available DSP compile tools I want to > understand the best or most efficient possible implementation suitable > for real time.
That depends how good you are at writing assembly code for your particular processor. Most modern C/C++ compilers are pretty darn good at optimization, but if you know what you're doing, you can still sometimes eke out some more cycles. I would recommend using a fully-C implementation at first, then profile the code to find the bottlenecks (where you're spending most of your time) and optimize those. You might get lucky and meet all of your requirements with the C implementation, at which time you can ship the product and take a vacation. Jason
rootpowers wrote:
> On Jul 25, 1:59 am, John <sampson...@gmail.com> wrote: >> On Jul 24, 1:49 pm, rootpowers <rootpow...@gmail.com> wrote: >> >> >> >>> I am new to this group and am looking for an answer for the following, >>> hope somebody can help. >>> How should the fixed point C code available from standard bodies like >>> ITU, ETSI be used. Is the reason one of the following or anything more >>> to it ? >>> (a) Use the fixed point C code only as a reference to do a *complete* >>> assembly level implementation on a fixed point DSP? I say this because >>> the fixed point C code is written in a fashion close to a DSP language >>> having ADD, SUB or MAC routines etc. >>> (b) Use the fixed-point C code and cross-compile using compile tools >>> from TI or Analog devices to generate assembly code. >>> Of the two options above 'a' or 'b', which yields the best results to >>> date and what is actuallt done in reality by commercial DSP based >>> companies that implement various codecs. >>> Thanks. >> Coding DSP projects in 100% assembly made sense in the old days of >> small program RAM and no hardware stack pointer -- think AD2105. I >> would not go back to that. I think a third option may be more common >> than the two you gave: >> >> (c) Use C code that calls hand written assembly language functions to >> do fixed point math operations on a block of numbers at a time. >> >> John > > John, > > Thanks for your response. From what you are saying - the best > implementation would be to use C code as a kind of "shell" program > that internally calls hand written assembly to do all the math, sounds > right. In that scenario, the cross compile tools would be useful, to > generate the final assembly and to push it on to the DSP, right ?
I'd recommend compiling EVERYTHING in C code to begin with. If you hit all your real-time deadlines then you don't need to re-write anything in assembly. If you can meet all your performance metrics with C code then why spend the time writing assembly? Not to mention the assembly is less portable and re-usable.
> How would the end product fare in comparison to the above method, if > the cross compile tools availabe today were to be used directly on the > fixed point C code itself and generate assembly code ?
That's a good starting point. If you find your performance is not good enough you should do some code profiling to find out which functions are consuming the most cycles and then replace those functions one at a time with C-callable assembly until you are meeting your performance targets.
> Will the > method mentioned first be far far superior to this method or just have > a marginal improvement ?
Try it out and let us know. This depends upon the code and the compiler so there's pretty much no way anyone could answer that for you. Also, what is your definition of "far superior"? Assembly + smaller code size + faster execution speed C + quicker to write + more portable If you're asking "will an assembly-only project be faster" then the answer is yes (if you're a decent assembly programmer). Will it be "better"? Depends on what you value. If you value time then no it's not better.
> The reason why this question comes is, from the availabe standard > fixed point code and the available DSP compile tools I want to > understand the best or most efficient possible implementation suitable > for real time.
Do it all in C to begin with and replace C functions with C-callable assembly functions as necessary. Brad
On Jul 25, 12:41 am, rootpowers <rootpow...@gmail.com> wrote:
> On Jul 25, 1:59 am, John <sampson...@gmail.com> wrote: > > > > > On Jul 24, 1:49 pm, rootpowers <rootpow...@gmail.com> wrote: > > > > I am new to this group and am looking for an answer for the following, > > > hope somebody can help. > > > > How should the fixed point C code available from standard bodies like > > > ITU, ETSI be used. Is the reason one of the following or anything more > > > to it ? > > > > (a) Use the fixed point C code only as a reference to do a *complete* > > > assembly level implementation on a fixed point DSP? I say this because > > > the fixed point C code is written in a fashion close to a DSP language > > > having ADD, SUB or MAC routines etc. > > > > (b) Use the fixed-point C code and cross-compile using compile tools > > > from TI or Analog devices to generate assembly code. > > > > Of the two options above 'a' or 'b', which yields the best results to > > > date and what is actuallt done in reality by commercial DSP based > > > companies that implement various codecs. > > > > Thanks. > > > Coding DSP projects in 100% assembly made sense in the old days of > > small program RAM and no hardware stack pointer -- think AD2105. I > > would not go back to that. I think a third option may be more common > > than the two you gave: > > > (c) Use C code that calls hand written assembly language functions to > > do fixed point math operations on a block of numbers at a time. > > > John > > John, > > Thanks for your response. From what you are saying - the best > implementation would be to use C code as a kind of "shell" program > that internally calls hand written assembly to do all the math, sounds > right. In that scenario, the cross compile tools would be useful, to > generate the final assembly and to push it on to the DSP, right ? > > How would the end product fare in comparison to the above method, if > the cross compile tools availabe today were to be used directly on the > fixed point C code itself and generate assembly code ? Will the > method mentioned first be far far superior to this method or just have > a marginal improvement ? > > The reason why this question comes is, from the availabe standard > fixed point code and the available DSP compile tools I want to > understand the best or most efficient possible implementation suitable > for real time.
The difference between a compiler's translation of fixed point C code and hand written assembly code depends on how aware the compiler is of the specific features of the chip. Those features include parallel load/store, parallel MAC, and special addressing modes -- which affect the speed of the code. They also include odd accumulator sizes (40 bits) and special saturation modes -- which affect the numerical results. By the time you coax your C compiler to take full advantage of the chip, the code will be far from portable, and you will have invested nearly as much time as handwritten assembly anyway. The major chip vendors offer fixed point assembly function libraries for many functions like FFT, filtering, transcendental functions, etc. It seems to me that C code calling down into those routines, plus some custom assembly routines where needed, is a good model. John
<cincydsp@gmail.com> wrote in message
news:1185365025.385266.171290@w3g2000hsg.googlegroups.com...
> > > > That depends how good you are at writing assembly code for your > particular processor. Most modern C/C++ compilers are pretty darn good > at optimization, but if you know what you're doing, you can still > sometimes eke out some more cycles.
The compilers can't use the DSP features in the efficient manner. Because of that the implementation of, say, IIR biquad section in C is ridiculously slow compared to the hand written code. The difference is as big as several times.
> I would recommend using a fully-C > implementation at first, then profile the code to find the bottlenecks > (where you're spending most of your time) and optimize those.
From my experience, the "average" DSP application spends ~50% of time calculating dot products.
> You > might get lucky and meet all of your requirements with the C > implementation, at which time you can ship the product and take a > vacation. > > Jason >
Vladimir Vassilevsky DSP and Mixed Signal Consultant www.abvolt.com