Forums

Code generation for ADSP-211xx SHARC processore

Started by Zong Chen May 15, 2004
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.
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?
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.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?
> > 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&#2013265929;s Aranguren Cardona jaac@sanjaac.com SanJaaC Electronics www.sanjaac.com
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
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