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

<c...@gmail.com> wrote in message
news:1...@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