Carlos wrote:
> > Has anybody investigated how efficient the SHARC ADSP-211xx processors
> > (i.e. SHARCs with two arithmetic units) can be utilised when
> > programmed in C? Put another way; how good is the VisualDSP c-compiler
> > at generation code that keeps booth arithmetic units busy? Anybody
> > that knows about relevant benchmarks?
> >
> > Z.C.
> 
> VDSP is ok.  There was one occasion when we had to write part of our FFT
> routine in assembler because VDSP hadn't quite got it optimised when
> compiling from C.  In any case, why not use 3rd party libraries which should
> have functions optimised for the SHARC, e.g. SpeedDSP?

That's usually not necessary, because VisualDSP comes with an
extensive optimized library - for example, FFT routines (why did you
roll your own?).


Regards,
Andor

Zong Chen wrote:
> Hi,
>
> Has anybody investigated how efficient the SHARC ADSP-211xx processors
> (i.e. SHARCs with two arithmetic units) can be utilised when
> programmed in C? Put another way; how good is the VisualDSP c-compiler
> at generation code that keeps booth arithmetic units busy? Anybody
> that knows about relevant benchmarks?
>
> Z.C.

VDSP is ok.  There was one occasion when we had to write part of our FFT
routine in assembler because VDSP hadn't quite got it optimised when
compiling from C.  In any case, why not use 3rd party libraries which should
have functions optimised for the SHARC, e.g. SpeedDSP?

Ta,
Carlos

> > Thanks for a very comprehensive response. The reason I am interested
> > in the SHARC DSPs is that I am looking for a DSP to do high precision
> > audio processing. I will have to use extended prec. p.f. arithmetic;
> > does that have any major bearing on the assembler complexity and/or
> > the excecution speed?
> > 

Hello,

I definitively agree with all of Al's comments, so I won't repeat the
same he said (wrote).

I've also been working on audio applications, and with no doubt, the
choice to go is SHARC, and prefereably programmed in assembly
language.

You could mix C/Asm, with the main structure of the program done in C,
but the real processing of the signals being done in ASM. One
advantage, concerning audio, is that the algorithms for this kind of
applications tend to be well mapped to the resources the SHARC family
of DSPs have (besides its peripherals, also the DSP core). I'd said
audio is one of the areas where DSPs like the SHARCs are an almost
perfect fit.

Moreover, you have extended floating point precision (40bit, 32bit
mantissa, 8 bit exponent) natively in the DSP, with no overhead at
all, which is amazing for what you want to do, don't you agree? I'm
not sure about the capabilities of the compiler for handling that data
type.

Additionally, programming in ASM will give you full control of the
SIMD capabilities of the DSP. At least until VDSP++ 3.0 (I don't know
how is it handled in VDSP++ 3.5), with C/C++ you could only use SIMD
on single channel operations. For example, if doing FIR filtering, PEx
would do the calculations over the odd indexed samples and coeffs, and
PEy would do the same but over the even indexed samples and coeffs, so
it would take almost half of the time. But you could't take advantage
of SIMD for multichannel operations.

I hope I helped you in making a decision.

Regards,

------------------------------
Jaime Andr�s Aranguren Cardona
jaac@sanjaac.com
SanJaaC Electronics
www.sanjaac.com

zong_chen@operamail.com (Zong Chen) wrote in
news:f61a10dc.0405151105.558044a@posting.google.com: 

> Al Clark <dsp@danvillesignal.com> wrote in message
> news:<Xns94EA65ACA8FBAaclarkdanvillesignal@66.133.130.30>... 
>> zong_chen@operamail.com (Zong Chen) wrote in 
>> news:f61a10dc.0405150509.6eebe49d@posting.google.com:
>> 
>> > Hi,
>> > 
>> > Has anybody investigated how efficient the SHARC ADSP-211xx
>> > processors (i.e. SHARCs with two arithmetic units) can be utilised
>> > when programmed in C? Put another way; how good is the VisualDSP
>> > c-compiler at generation code that keeps booth arithmetic units
>> > busy? Anybody that knows about relevant benchmarks?
>> > 
>> > Z.C.
>> > 
>> 
>> Generally speaking the SHARC has an architecture that is well suited
>> for C. It has many index registers (pointers) and a flexible register
>> set. 
>> 
>> In our view, C is not ideal for DSP applications. We write all of our
>> DSP code in assembly, which in the case of the SHARC is very easy.
>> The ADI assembly language is probably the most readable assembly code
>> that I have ever seen for any processor.
>> 
>> The ease of assembly language programming for the SHARC may very well
>> be one of its "hidden" advantages. From everything I've heard, the
>> SHARC's TI competition is very difficult to program in assembly. This
>> means that a SHARC of similar speed might execute much faster since
>> the programmer is more apt to write its program directly in assembly
>> whereas the TI application is more likely relying on a compiler. This
>> is just a theory, I haven't tested the idea.
>> 
>> The main issues with C is that you have to save way to many resources
>> every time you make a call or vector to an ISR. For example, the
>> super fast interrupt handler has thirty cycles of overhead before you
>> actually do the work of the function.
>> 
>> A similar assembly routine might enable some secondary DAGs and 
>> registers, and then execute. This means maybe 3-4 instructions of 
>> overhead.
>> 
>> I think that many people choose C as an excuse not to learn the
>> assembly language. I would suggest that this is a very bad reason to
>> choose C. If you use C, you still need to learn the assembly
>> language. 
>> 
>> There are many prewritten functions with VDSP both in C and ASM. The
>> C Calls are basically wrappers around an assembly routine with the
>> same name. SIMD functions exist, and therefore are taken advantage of
>> where appropriate.
>> 
>> I heard someone report that a C program might run at 1/3 the speed of
>> an equivalent assembly program. 
> 
> Which might be why AD recommend mixed C/assembler. Judging from the C
> compiler and library manual this mixin appears a bit messy, so it
> might well be better to spend the time writing assembler code.
> 
>> If this is the case, I believe it is 
>> probably due to all the forementioned function call overhead and the
>> fact that secondary registers are ignored.
>>  
>> 
>> -- 
>> Al Clark
>> Danville Signal Processing, Inc.
>> --------------------------------------------------------------------
>> comp.dsp conference July 28 - Aug 1, 2004
>> 
>> details at http://www.danvillesignal.com/index.php?id=compdsp
>> email: compdsp@danvillesignal.com
>> 
>> Who says you can't teach an old dog a new DSP trick?
> 
> Thanks for a very comprehensive response. The reason I am interested
> in the SHARC DSPs is that I am looking for a DSP to do high precision
> audio processing. I will have to use extended prec. p.f. arithmetic;
> does that have any major bearing on the assembler complexity and/or
> the excecution speed?
> 
> A possible alternative might be a Blackfin DSP, coded in C. It is
> saied to have a RISC-like architecture, so it might be a more
> palatable target for the code generator? However, the precision
> requirements would mean using double precison arithmetic, which would
> probably slow down things too much. My imediate impression of the
> Blackfins is that it might be good mixed audio/video with a bit of
> general purpose tasks thrown in, or?

I agree.

> 
> Z.C.
> 

Unless power consumption is an issue, I think you will find the the SHARC 
is a much better choice. It nice to have both floating point and fixed 
point capability at high precision.

The SHARC has become the dominant DSP in audio space. We are doing at 
least 80% of our work with the new ADSP-21262. This part works very well 
for audio applications. 





-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
comp.dsp conference July 28 - Aug 1, 2004

details at http://www.danvillesignal.com/index.php?id=compdsp
email: compdsp@danvillesignal.com

Who says you can't teach an old dog a new DSP trick?

Al Clark <dsp@danvillesignal.com> wrote in message news:<Xns94EA65ACA8FBAaclarkdanvillesignal@66.133.130.30>...
> zong_chen@operamail.com (Zong Chen) wrote in 
> news:f61a10dc.0405150509.6eebe49d@posting.google.com:
> 
> > Hi,
> > 
> > Has anybody investigated how efficient the SHARC ADSP-211xx processors
> > (i.e. SHARCs with two arithmetic units) can be utilised when
> > programmed in C? Put another way; how good is the VisualDSP c-compiler
> > at generation code that keeps booth arithmetic units busy? Anybody
> > that knows about relevant benchmarks?
> > 
> > Z.C.
> > 
> 
> Generally speaking the SHARC has an architecture that is well suited for 
> C. It has many index registers (pointers) and a flexible register set. 
> 
> In our view, C is not ideal for DSP applications. We write all of our DSP 
> code in assembly, which in the case of the SHARC is very easy. The ADI 
> assembly language is probably the most readable assembly code that I have 
> ever seen for any processor.
> 
> The ease of assembly language programming for the SHARC may very well be 
> one of its "hidden" advantages. From everything I've heard, the SHARC's 
> TI competition is very difficult to program in assembly. This means that 
> a SHARC of similar speed might execute much faster since the programmer 
> is more apt to write its program directly in assembly whereas the TI 
> application is more likely relying on a compiler. This is just a theory, 
> I haven't tested the idea.
> 
> The main issues with C is that you have to save way to many resources 
> every time you make a call or vector to an ISR. For example, the super 
> fast interrupt handler has thirty cycles of overhead before you actually 
> do the work of the function.
> 
> A similar assembly routine might enable some secondary DAGs and 
> registers, and then execute. This means maybe 3-4 instructions of 
> overhead.
> 
> I think that many people choose C as an excuse not to learn the assembly 
> language. I would suggest that this is a very bad reason to choose C. If 
> you use C, you still need to learn the assembly language.
> 
> There are many prewritten functions with VDSP both in C and ASM. The C 
> Calls are basically wrappers around an assembly routine with the same 
> name. SIMD functions exist, and therefore are taken advantage of where 
> appropriate.
> 
> I heard someone report that a C program might run at 1/3 the speed of an 
> equivalent assembly program. 

Which might be why AD recommend mixed C/assembler. Judging from the C
compiler and library manual this mixin appears a bit messy, so it
might well be better to spend the time writing assembler code.

> If this is the case, I believe it is 
> probably due to all the forementioned function call overhead and the fact 
> that secondary registers are ignored.
>  
> 
> -- 
> Al Clark
> Danville Signal Processing, Inc.
> --------------------------------------------------------------------
> comp.dsp conference July 28 - Aug 1, 2004
> 
> details at http://www.danvillesignal.com/index.php?id=compdsp
> email: compdsp@danvillesignal.com
> 
> Who says you can't teach an old dog a new DSP trick?

Thanks for a very comprehensive response. The reason I am interested
in the SHARC DSPs is that I am looking for a DSP to do high precision
audio processing. I will have to use extended prec. p.f. arithmetic;
does that have any major bearing on the assembler complexity and/or
the excecution speed?

A possible alternative might be a Blackfin DSP, coded in C. It is
saied to have a RISC-like architecture, so it might be a more
palatable target for the code generator? However, the precision
requirements would mean using double precison arithmetic, which would
probably slow down things too much. My imediate impression of the
Blackfins is that it might be good mixed audio/video with a bit of
general purpose tasks thrown in, or?

Z.C.

zong_chen@operamail.com (Zong Chen) wrote in 
news:f61a10dc.0405150509.6eebe49d@posting.google.com:

> Hi,
> 
> Has anybody investigated how efficient the SHARC ADSP-211xx processors
> (i.e. SHARCs with two arithmetic units) can be utilised when
> programmed in C? Put another way; how good is the VisualDSP c-compiler
> at generation code that keeps booth arithmetic units busy? Anybody
> that knows about relevant benchmarks?
> 
> Z.C.
> 

Generally speaking the SHARC has an architecture that is well suited for 
C. It has many index registers (pointers) and a flexible register set. 

In our view, C is not ideal for DSP applications. We write all of our DSP 
code in assembly, which in the case of the SHARC is very easy. The ADI 
assembly language is probably the most readable assembly code that I have 
ever seen for any processor.

The ease of assembly language programming for the SHARC may very well be 
one of its "hidden" advantages. From everything I've heard, the SHARC's 
TI competition is very difficult to program in assembly. This means that 
a SHARC of similar speed might execute much faster since the programmer 
is more apt to write its program directly in assembly whereas the TI 
application is more likely relying on a compiler. This is just a theory, 
I haven't tested the idea.

The main issues with C is that you have to save way to many resources 
every time you make a call or vector to an ISR. For example, the super 
fast interrupt handler has thirty cycles of overhead before you actually 
do the work of the function.

A similar assembly routine might enable some secondary DAGs and 
registers, and then execute. This means maybe 3-4 instructions of 
overhead.

I think that many people choose C as an excuse not to learn the assembly 
language. I would suggest that this is a very bad reason to choose C. If 
you use C, you still need to learn the assembly language.

There are many prewritten functions with VDSP both in C and ASM. The C 
Calls are basically wrappers around an assembly routine with the same 
name. SIMD functions exist, and therefore are taken advantage of where 
appropriate.

I heard someone report that a C program might run at 1/3 the speed of an 
equivalent assembly program. If this is the case, I believe it is 
probably due to all the forementioned function call overhead and the fact 
that secondary registers are ignored.
 

-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
comp.dsp conference July 28 - Aug 1, 2004

details at http://www.danvillesignal.com/index.php?id=compdsp
email: compdsp@danvillesignal.com

Who says you can't teach an old dog a new DSP trick?

Hi,

Has anybody investigated how efficient the SHARC ADSP-211xx processors
(i.e. SHARCs with two arithmetic units) can be utilised when
programmed in C? Put another way; how good is the VisualDSP c-compiler
at generation code that keeps booth arithmetic units busy? Anybody
that knows about relevant benchmarks?

Z.C.