What Language do You Use?

All of my DSP experience has been confined to C and C++, with enough 
assembly language thrown in to keep my code fast and my life 
interesting.  Having worked with dedicated ADA programmers I understand 
that the only reason this doesn't condem me to having hairy knuckles is 
because dragging them on the ground keeps the hair scraped off.

But it makes me wonder -- what language do _you_ do DSP in, why, why do 
you like it, and what would you have it do differently if you could? 
For completeness, do you do real-time embedded DSP or do you do off-line 
processing, and what processor(s) do you write for?

My answers are:

I do real time DSP, but often it's for motion control systems that only 
need to turn over at 100Hz or so.  When I need to do DSP at 10-s of kHz 
I use real DSP chips, for 100Hz stuff I generally end up using 16-bit 
CISC or 32-bit RISC processors.  I occasionally do algorithms for folks 
doing video processing on FPGAs, but I don't have to write any code for 
that.

My languages of choice are C, C++, and assembly; I use C when I have to 
and judicious small bits of assembly when I _really_ have to (for 
special data types on CISC machines and for core algorithms if the 
compiler doesn't know how to generate MAC instructions).  I have worked 
on many projects that wrap the "real" DSP code with many many lines of 
communication and executive control code, so if I'm lucky I get a 
machine with tools that support C++ and I use that language for all of 
the "peripheral" stuff.

What I would like to see different is some sort of fractional data type 
in C.  I'm not holding my breath.  I have written fractional data type 
code for C (very clunky) and C++ (very natural looking).  It has caused 
a speed hit which would not be nearly as bad if it were built in, but it 
is still way faster than floating point on almost all of the processors 
I have used (newer Pentiums and the TI '2812 are exceptions).

-------------------------------------------
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Simulink/C/Assembly  is in my toolchest, Simulink is like a high speed
tablesaw, C a hand powered saw and assembly a hand saw, use them as the
task requires, got to have them all and I make no attempt to throw any
of them out. SHARC is my main floating point processor and have used a
variety of TI/ADI fixed point processors and just getting into ARM's.

I do all fixed point math in assembly, trying to do it in C or C++ is
like using a table saw to cut intricate details in a a piece of wood, I
suppose it could be done, but the end product would be of low quality.

Not sure why your fixed point is way faster then floating, modern
floating point hardware is just as fast as fixed point (but with the
power/size hit of course), unless you comparing software emulated float
with fixed.

"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:11booivg57asm3c@corp.supernews.com...
> But it makes me wonder -- what language do _you_ do DSP in, why, why do 
> you like it, and what would you have it do differently if you could? For 
> completeness, do you do real-time embedded DSP or do you do off-line 
> processing, and what processor(s) do you write for?
>

Hello Tim,

My last few projects have all used Mot 56300 series DSPs (all programmed in 
assembler). A couple of projects use Rabbit processors as ancillary 
processors and they perform some high level processing and TCP/IP tasks. The 
Rabbit acts as a web site to allow for user operation and offers FTP for 
data transfer both in and out.   Other applications have the DSP card 
plugged into a either PCI bus or an AT bus and the PC acts the ancillary 
processor. I've been programming Mot DSPs for so long now, that I have a lot 
of code already written, so reuse is easy. I started with the 56001 (1988) 
and worked up from there. I did have a side project with the TI '549 and the 
software tools at the time were horrid - the c compiler was almost unusable. 
And the assembler failed to warn of pipeline issues.  I'm told that this is 
much improved now. But I stick with what I know. Most of my work is in 
telephony and digital receivers. Assembly gives me the control and the speed 
I need. All of my DSP apps are real time.

Clay

 

steve wrote:

> Simulink/C/Assembly  is in my toolchest, Simulink is like a high speed
> tablesaw, C a hand powered saw and assembly a hand saw, use them as the
> task requires, got to have them all and I make no attempt to throw any
> of them out. SHARC is my main floating point processor and have used a
> variety of TI/ADI fixed point processors and just getting into ARM's.
> 
> I do all fixed point math in assembly, trying to do it in C or C++ is
> like using a table saw to cut intricate details in a a piece of wood, I
> suppose it could be done, but the end product would be of low quality.
> 
> Not sure why your fixed point is way faster then floating, modern
> floating point hardware is just as fast as fixed point (but with the
> power/size hit of course), unless you comparing software emulated float
> with fixed.
> 
I like the saw analogy.

When I have the opportunity to use a processor with modern 
floating-point hardware the fixed point _is_ slower -- but that's 
outside of the price point for many of the systems that I currently work 
on or have worked on in the past.

New, "real" DSP chips, even fixed-point ones, appear to have enough 
floating point support to rival doing math with sufficiently-protected 
fixed-point code, unless you resort to assembly code routines to 
implement your filters (which, oddly enough is what I do).

I expect that the floating point hardware (or at least support) will 
migrate down the price scale until it's everywhere and kids won't know 
what we talk about when we reminisce about using fixed point (or 
assembly, for that matter).

-------------------------------------------
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

"Tim Wescott" <tim@seemywebsite.com> wrote in message
news:11booivg57asm3c@corp.supernews.com...
> All of my DSP experience has been confined to C and C++, with enough
> assembly language thrown in to keep my code fast and my life
> interesting.  Having worked with dedicated ADA programmers I understand
> that the only reason this doesn't condem me to having hairy knuckles is
> because dragging them on the ground keeps the hair scraped off.
>
> But it makes me wonder -- what language do _you_ do DSP in, why, why do
> you like it, and what would you have it do differently if you could?
> For completeness, do you do real-time embedded DSP or do you do off-line
> processing, and what processor(s) do you write for?
>
> My answers are:
>
> I do real time DSP, but often it's for motion control systems that only
> need to turn over at 100Hz or so.  When I need to do DSP at 10-s of kHz
> I use real DSP chips, for 100Hz stuff I generally end up using 16-bit
> CISC or 32-bit RISC processors.  I occasionally do algorithms for folks
> doing video processing on FPGAs, but I don't have to write any code for
> that.
>
> My languages of choice are C, C++, and assembly; I use C when I have to
> and judicious small bits of assembly when I _really_ have to (for
> special data types on CISC machines and for core algorithms if the
> compiler doesn't know how to generate MAC instructions).  I have worked
> on many projects that wrap the "real" DSP code with many many lines of
> communication and executive control code, so if I'm lucky I get a
> machine with tools that support C++ and I use that language for all of
> the "peripheral" stuff.
>
> What I would like to see different is some sort of fractional data type
> in C.  I'm not holding my breath.  I have written fractional data type
> code for C (very clunky) and C++ (very natural looking).  It has caused
> a speed hit which would not be nearly as bad if it were built in, but it
> is still way faster than floating point on almost all of the processors
> I have used (newer Pentiums and the TI '2812 are exceptions).
>
> -------------------------------------------
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com


Well it's a question of availability.. just how many pascal, ada or basic
compilers can
one find for DSP's ?!!

I have used assembler, C, C++ and Forth on dsp's.. mostly C and asm of
late..
most dsp developers I presume are speed freaks.. so need the most efficient
code possible.. hence no "Visual Basic" for dsp's !!!!!

I write all my DSP code in assembly. In the last 10 years, this has been 
either Analog Devices 21xx or SHARC, but I have worked with DSPs from 
four different manufacturers. 

The SHARC and the 21xx DSP families have a very readable, somewhat C like 
assembly language. I don't think that most DSP code is really that 
portable from one processor to another so I don't think this is a good 
reason to use C. In most DSPs, you accomplish a lot with one instruction 
so in some ways, the assembly is already kind of a mid level language.
With the exception of a switch statement (I use a jump table), I don't 
see much advantage to C. Nevertheless, I know that many people use C for 
the SHARC and we will probably rewrite all of our example code in both 
assembly and C versions.

I think that the extra overhead in C, doesn't justify the small 
advantages that C offers for DSP applications. I might have a different 
opinion if I was working with other devices. We have an internal Blackfin 
project that I think we may do in C.

I am not anti-C, I used to write all my general purpose embedded code in 
C (primarily 8051), but I don't think it is an ideal language for DSP.

I can't think of any other high (mid?) level languages that are even 
available for DSP with the exception of Matlab. 

-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com








Tim Wescott <tim@seemywebsite.com> wrote in 
news:11booivg57asm3c@corp.supernews.com:

> All of my DSP experience has been confined to C and C++, with enough 
> assembly language thrown in to keep my code fast and my life 
> interesting.  Having worked with dedicated ADA programmers I understand 
> that the only reason this doesn't condem me to having hairy knuckles is 
> because dragging them on the ground keeps the hair scraped off.
> 
> But it makes me wonder -- what language do _you_ do DSP in, why, why do 
> you like it, and what would you have it do differently if you could? 
> For completeness, do you do real-time embedded DSP or do you do off-
line 
> processing, and what processor(s) do you write for?
> 
> My answers are:
> 
> I do real time DSP, but often it's for motion control systems that only 
> need to turn over at 100Hz or so.  When I need to do DSP at 10-s of kHz 
> I use real DSP chips, for 100Hz stuff I generally end up using 16-bit 
> CISC or 32-bit RISC processors.  I occasionally do algorithms for folks 
> doing video processing on FPGAs, but I don't have to write any code for 
> that.
> 
> My languages of choice are C, C++, and assembly; I use C when I have to 
> and judicious small bits of assembly when I _really_ have to (for 
> special data types on CISC machines and for core algorithms if the 
> compiler doesn't know how to generate MAC instructions).  I have worked 
> on many projects that wrap the "real" DSP code with many many lines of 
> communication and executive control code, so if I'm lucky I get a 
> machine with tools that support C++ and I use that language for all of 
> the "peripheral" stuff.
> 
> What I would like to see different is some sort of fractional data type 
> in C.  I'm not holding my breath.  I have written fractional data type 
> code for C (very clunky) and C++ (very natural looking).  It has caused 
> a speed hit which would not be nearly as bad if it were built in, but 
it 
> is still way faster than floating point on almost all of the processors 
> I have used (newer Pentiums and the TI '2812 are exceptions).
> 
> -------------------------------------------
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

Hello!

I am fairly new to DSP (3 months old child :-) ). Most of my efforts go
for PowerPC. I use C++ most of the time because of initialization and
release ease. I sometimes also use Objective-C. But I haven't used
assembly for any of them. Thats because (to be true) am still not sure,
where assembly should enter. I think it needs a little more experience
before I start deciding as to where should I introduce assembly in my
code.

Can any one of you lend me your code with some inline assembly, which
tells why that particular segment was added. It would be very helpful.

Thanks and regards
--Himanshu

Normally English.

Rimmer

Tim Wescott wrote:
> All of my DSP experience has been confined to C and C++, with enough
> assembly language thrown in to keep my code fast and my life
> interesting.  Having worked with dedicated ADA programmers I understand
> that the only reason this doesn't condem me to having hairy knuckles is
> because dragging them on the ground keeps the hair scraped off.
>
> But it makes me wonder -- what language do _you_ do DSP in, why, why do
> you like it, and what would you have it do differently if you could?
> For completeness, do you do real-time embedded DSP or do you do off-line
> processing, and what processor(s) do you write for?
>
> My answers are:
>
> I do real time DSP, but often it's for motion control systems that only
> need to turn over at 100Hz or so.  When I need to do DSP at 10-s of kHz
> I use real DSP chips, for 100Hz stuff I generally end up using 16-bit
> CISC or 32-bit RISC processors.  I occasionally do algorithms for folks
> doing video processing on FPGAs, but I don't have to write any code for
> that.
>
> My languages of choice are C, C++, and assembly; I use C when I have to
> and judicious small bits of assembly when I _really_ have to (for
> special data types on CISC machines and for core algorithms if the
> compiler doesn't know how to generate MAC instructions).  I have worked
> on many projects that wrap the "real" DSP code with many many lines of
> communication and executive control code, so if I'm lucky I get a
> machine with tools that support C++ and I use that language for all of
> the "peripheral" stuff.
>
> What I would like to see different is some sort of fractional data type
> in C.  I'm not holding my breath.  I have written fractional data type
> code for C (very clunky) and C++ (very natural looking).  It has caused
> a speed hit which would not be nearly as bad if it were built in, but it
> is still way faster than floating point on almost all of the processors
> I have used (newer Pentiums and the TI '2812 are exceptions).
>
> -------------------------------------------
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

Here's my two cent contribution to the survey.

I started writing "real" DSP code in the early 1990s using the
ADSP2101, 2105, 2115, etc. It was 100% assembly, using ADI's algebraic
syntax. I never tried the C compilers available for those chips, mainly
because I was really trying to squeeze alot into them. Typically my
projects would spread out across multiple programs swapped in and out.
For example, a half-duplex transmitter would reboot between tx and rx.
I used a ROM emulator and oscilloscope to debug. Never tried the chip
emulator.

Then I switched to the '54XX and C. I use the compiler intrinsics and
assembly subroutines to get speed. '54XX assembly is more difficult
than the simple AD21XX, IMO. I have not tried the BIOS or CSL, or
Visual Linker. I pretty much find a formula that works and stick with
it -- don't enjoy learning new tools / paradigms to do the same thing I
already know how to do, and hate the bugs even more. I just got the new
"Platinum" CCS 3.1 IDE in the mail. The prior editions are the most
crash-prone Windows apps I have ever used, and the situation does not
seem to have improved in the last 5+ years of releases.

I have done quite a bit of DSP work for the X86 under Linux and
Windows, using C and Fortran. Sometimes I use the Intel signal
processing library routines. Often my stuff gets "wrapped" in C++ by
others. I don't use C++ for DSP work.

John

Tim Wescott wrote:
> All of my DSP experience has been confined to C and C++, with enough
> assembly language thrown in to keep my code fast and my life
> interesting.  Having worked with dedicated ADA programmers I understand
> that the only reason this doesn't condem me to having hairy knuckles is
> because dragging them on the ground keeps the hair scraped off.
>
> But it makes me wonder -- what language do _you_ do DSP in, why, why do
> you like it, and what would you have it do differently if you could?
> For completeness, do you do real-time embedded DSP or do you do off-line
> processing, and what processor(s) do you write for?

I first learned computer programming with something called "LOGO"
(don't know if it was international or some Norwegian educational
stuff)
around 1986-87, learned Pascal and x86 Assembly around 1989-90, I then
went to C in 1993 and C++ in 1995-96 before I ended up with matlab in
late 1996. Suffice it to say that after 1995, I never saw much point
in (let alone was motivated to) learning yet another programming
language.

Most of my work have been directed at off-line processing of large
amounts of data, although I have been involved with real-time
applications.

I choose to stick with C/C++ for production code, since C/C++ is
fairly standardized and available on all relevant platforms. Complex
numbers were included in the Standard Template Library (STL), and
numerical libraries are available (apparently, Intel provides
a BLAS/LAPACK library) while Qt provides portable GUI code. Matlab
is essential for testing ideas and prototyping.

What to do differently... learning the programming tools early on.
I am happy with the matlab + C/C++ combo. It's not ideal in all
respects, but I find it to be a reasonable compromise between rapid
testing of ideas and fast, portable code. 

Rune