Three years ago I developed a very fast set of two-word floating-point assembler routines for the ADSP-2187, including a square root function and conversion to/from IEEE-754, callable from C. The code was used very successfully for a Kalman tracking implementation and ran over 10 times faster than the original code written entirely in C. It's now running on an ADSP-2191. I'm in the process of porting these routines to the Blackfin. If anyone is interested in this stuff, please get in touch. Leon -- Leon Heller, G1HSM leon_heller@hotmail.com http://www.geocities.com/leon_heller
Blackfin two-word *fast* floating-point library
Started by ●July 19, 2003
Reply by ●July 19, 20032003-07-19
"Leon Heller" <leon_heller@hotmail.com> wrote in message news:bfb2t1$h4u$1@sparta.btinternet.com...> Three years ago I developed a very fast set of two-word floating-point > assembler routines for the ADSP-2187, including a square root function and > conversion to/from IEEE-754, callable from C. The code was used very > successfully for a Kalman tracking implementation and ran over 10 times > faster than the original code written entirely in C. It's now running onan> ADSP-2191. > > I'm in the process of porting these routines to the Blackfin. If anyone is > interested in this stuff, please get in touch.I've just found that ADI has already done most of this: see EE-186. 8-) Leon -- Leon Heller, G1HSM leon_heller@hotmail.com http://www.geocities.com/leon_heller
Reply by ●July 19, 20032003-07-19
Leon Heller wrote:> > Three years ago I developed a very fast set of two-word floating-point > assembler routines for the ADSP-2187, including a square root function and > conversion to/from IEEE-754, ...Leon, For shame! You are to be chided for your retrogressive approach to programming. Assembler routines, indeed! That's not the modern way at all. Have you no professional standards to uphold? We all know that assembly language and logic gates are quite pass�, supplanted in the modern world by high-level abstractions that render them obsolete. It wouldn't surprise me to learn that you resharpen knives instead of replacing them. If enough people follow your example, it's no wonder that our economy is in shambles. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 19, 20032003-07-19
"Leon Heller" <leon_heller@hotmail.com> wrote in news:bfb2t1$h4u$1@sparta.btinternet.com:> Three years ago I developed a very fast set of two-word floating-point > assembler routines for the ADSP-2187, including a square root function > and conversion to/from IEEE-754, callable from C. The code was used > very successfully for a Kalman tracking implementation and ran over 10 > times faster than the original code written entirely in C. It's now > running on an ADSP-2191. > > I'm in the process of porting these routines to the Blackfin. If > anyone is interested in this stuff, please get in touch. > > LeonLeon: If you are interested, we could put the 21xx routines on the developers page of our web site. We have several 218x & 219x products. At some point in the future, we will have Blackfin products as well. This is an open invitation to anyone who wants to contribute. Our interest is to expand our site to include "ADI DSP tricks" and useful library routines. Code could be for 218x, 219x, Blackfin or Sharc. I would like a simple release (similar to dsp guru) that states that this is your work, and that we have permission to share it. Obviously, our interest is to increase traffic to our site and to facilitate the sale of more boards. One of these days, I might rewrite my DC Block algorithm to use fraction saving per rbj's dspguru trick. This would be an example of the kind of things we are looking for. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
Reply by ●July 20, 20032003-07-20
Jerry Avins wrote:> > For shame! You are to be chided for your retrogressive approach to > programming. Assembler routines, indeed! That's not the modern way at > all. Have you no professional standards to uphold?Real men still program DSPs in assembly and only cowards write in high level languages. :-) -- --... ...-- Ramakrishnan
Reply by ●July 21, 20032003-07-21
Ramakrishnan Muthukrishnan <rkrishnan@ti.com> wrote in message news:<3F1ACC3C.43268D68@ti.com>...> Jerry Avins wrote: > > > > For shame! You are to be chided for your retrogressive approach to > > programming. Assembler routines, indeed! That's not the modern way at > > all. Have you no professional standards to uphold? > > Real men still program DSPs in assembly and only cowards write in high > level languages. :-)I really liked this reply!!! Just ignoring the assembly language of the processor being used is to throw away all the internal powerful features of the chip. Of course, not only assembly language is enough, nowadays when time-to-market is an important design concern. JaaC
Reply by ●July 22, 20032003-07-22
KG7HF wrote:> > Sounds like a fairly rigid and inflexible statement. So if I write my > application in binary, skipping the assembler and linker, am I a god or aNo no. God always wrote in Lisp[1], you know? :-) So you can't be god if you write in binary.> fool? Use of the language which performs the necessary task, seems to me to > be a more rational choice.Writing in high level language without understanding the architecture will produce non-optimal code. Otherwise, you will not see those job openings for DSP programmers. If your task doesn't demand performance, you can afford to do that. Try writing an FIR filter code for some processor which has, say more than one MAC units, and see the assembler output. You will know. [1] http://www.gnu.org/fun/jokes/eternal-flame.html -- --... ...-- Ramakrishnan
Reply by ●July 22, 20032003-07-22
Ramakrishnan Muthukrishnan wrote:> > one MAC units, and see the assembler output. You will know.^^^^^^^^^ I mean compiler output... Over use of using assembler instead of compiler... :-) -- --... ...-- Ramakrishnan
Reply by ●July 22, 20032003-07-22
Sounds like a fairly rigid and inflexible statement. So if I write my application in binary, skipping the assembler and linker, am I a god or a fool? Use of the language which performs the necessary task, seems to me to be a more rational choice. PD "Ramakrishnan Muthukrishnan" <rkrishnan@ti.com> wrote in message news:3F1ACC3C.43268D68@ti.com...> Jerry Avins wrote: > > > > For shame! You are to be chided for your retrogressive approach to > > programming. Assembler routines, indeed! That's not the modern way at > > all. Have you no professional standards to uphold? > > Real men still program DSPs in assembly and only cowards write in high > level languages. :-) > > -- > --... ...-- > Ramakrishnan
Reply by ●July 22, 20032003-07-22
KG7HF wrote:> > Sounds like a fairly rigid and inflexible statement. So if I write my > application in binary, skipping the assembler and linker, am I a god or a > fool? Use of the language which performs the necessary task, seems to me to > be a more rational choice. > > PD > > "Ramakrishnan Muthukrishnan" <rkrishnan@ti.com> wrote in message > news:3F1ACC3C.43268D68@ti.com... > > Jerry Avins wrote: > > > > > > For shame! You are to be chided for your retrogressive approach to > > > programming. Assembler routines, indeed! That's not the modern way at > > > all. Have you no professional standards to uphold? > > > > Real men still program DSPs in assembly and only cowards write in high > > level languages. :-) > > > > -- > > --... ...-- > > RamakrishnanFirst, I had hoped that the tongue in my cheek would have been evident. Second, there are constructions and optimizations that assembler can do but that any particular higher-level language can't; binary can do no more. The point is not to write code the hard way, but to have the skill to use the processor's resources to the utmost when necessary. As a matter of fact (a silly clich� indeed!), I have found it useful to program in binary. The occasions were all limited to patching code already in ROM, the code snippets were all short, but there you are. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
