Writing DSP algorithms directly in C or assembly? [closed]

Question

I m working on a DSP project(IIR filtering) on an Analog Devices digital signal processor(BF706) with the compiler suite coming with it, CrossCore Studio. It has some examples for simple DSP stuff like FIR and IIR filters and library functions for it. The processor manual describes the assembly instruction set and doesn't comment on C.

MY question arises from this particular application, but I thought there is a best practice that DSP developers follow. So I will frame it in a general way:

What I have realized by the examples coming with this DSP, is that if I want to use the circuits designed for DSP applications I need to program in assembly to directly run those instructions.(like multiply and add, etc. ) My question is if I just program in C, wouldn't the compiler(which also comes from the DSP chip company) optimize it for that DSP and use its capabilities? Or do I really need to write DSP routines directly in assembly?

Answer 1

It's always better to have your algorithm implemented in a higher-level language (which C is compared to assembly), even if you plan to implement everything in assembly in the end.

• chances are, you won't even need assembly. If the code generated by your compiler meets your design goals, your job is done.

• if not, you won't be starting your assembly coding from scratch. Let the compiler generate the initial code for you, and use that as a base for your optimized assembly version.

• later, when you'll need to test your optimized assembly code, you'll be glad to have the C version. Instead of manually calculating the correct output for your test input data, you can just feed that input data to your unoptimized C implementation, then check that the assembly produces exactly the same output after the optimizations you have made.

If, after a few years a new developer will need to make modifications to your algorithm and all they have at hand is a highly optimized assembly code, there's a high chance they'll have to start from scratch.

Answer 2

If the compiler writers put some effort into optimizing it for that target, it will at least make some use of the special DSP instructions / architecture. But for ultimate performance it will never be as good as hand-tuned assembly. It might be plenty good enough, though - depends on your application.

Other alternatives include:

1. Write the majority of your program in C, and just the most critical numerical portion in assembly.
2. Write the program in C and use libraries supplied by the manufacturer or third parties - if you're doing common DSP tasks such as FFTs, FIR / IIR filters etc somebody has probably already written the hand-tuned machine code to do it, so you can use that (you may have to pay for it) and link it to your application.

Answer 3

Premature optimization is the root of all evil. - Donald Knuth

When you find that you don't get enough performance from your code, profile your program first, find the bottlenecks, analyze your performance requirements, and only then start doing optimizations. Writing assembly code is last resort.

My question is if I just program in C, wouldn't the compiler(which also comes from the DSP chip company) optimize it for that DSP and use its capabilities?

Yes, C compiler can do a fair amount of optimization. But this depends on the quality of the compiler. Frequently, a human can write faster assembly code than the compiled C code. At great expense of human pain and suffering, that is.

Or do I really need to write DSP routines directly in assembly?

First write in C, then profile, then decide if you need to write in assembly. Hopefully, you would not need the assembly.

Answer 4

Your DSP will be advertised with a maximum sustained MACs, assuming all the pipes are filled. That is obviously an upper limit to what can be achieved. You know how many MACs your filters and other processing will take, from your analysis. Aim to have the first at least twice the second, as you will not be able to keep the DSP core running at maximum. Just as you would not try to fill an FPGA above 70% resource (PAR gets very slow above that), development could get very slow trying to squeeze the last few theoretical MACs out of a DSP.

You will code your whole application in C. It's impractical to write all the extra, necessary stuff in assembler, test injection and visibility, housekeeping etc. Write a C version of the test filter. Write an assembler version of the same filter, to verify you can in fact write assembler for this beast.

Now do some timings. Use an RTOS approved by the supplier. Compare the run time of your test assembler module to a C version. If they're within a few percent, move on. If it's triple, then read the documentation, quiz the vendor, and find out why the compiler isn't tuning it. You may need to learn to write its flavour of C as much as to set the correct compiler flags, it will be quicker to find out how to drive the compiler properly than to rewrite everything in assembler.

You've done all this before committing to a DSP, to a tool chain.

Once you have a toolchain you can work with, a compiler you can tune to get reasonably close to maximum, a DSP with some timing headroom left, then you can be reasonably confident that very few parts of your code suite will need to be put into assembler to finish the job.

Answer 5

Even though I answered this question already, I will add another answer to illustrate a different viewpoint:

Write in C, read in assembly!

So, instead of writing in assembly, you will write the logic in C, carefully making sure that the assembler output of the C code is optimal. You can often do certain tricks on the C code to affect the assembler output. Use static inline functions when it makes sense. If you need to use some special instructions the DSP supports, make a static inline function abstraction of the special instruction, and call the special instruction using the abstraction.

Although I have to say I have never programmed DSPs, this approach of writing the C code while carefully observing the compiled assembly has worked for me on x86 machines extremely well. So well, in fact, that I have never had to write anything in assembly to obtain the best possible performance. I will instead of optimizing the assembly code modify the C code in such manner that the assembly is optimal.

Of course, this depends on good C compilers being available. For x86 such compilers are available (you often have to specify a higher optimization level than the default). For DSPs, I frankly don't know if the compilers are as good.

The benefit of this approach is that you have a single portable codebase, optimized to result in optimal assembly for a given DSP, but it works also if the DSP is changed to something else. Of course you may have to slightly adjust the C code to obtain best possible performance on the new DSP.

Answer 6

In general, it is not necessary to write assembler sources if:

• you optimize C in the critical sections: a good usage of "register" keyword, inline functions, ...
• could be some functions of the C program using asm blocks

That means review manually the assembler generated by the C compiler (for the critical parts) and modify the source until enough level of optimization.

Answer 7

I would say here that if you do FIR / IIR filters, it is far more important which algorithm you use (the trivial algorithm versus fast Fourier transform (FFT)) than which language you use (C versus assembly).

Would I write FFT in assembly? Probably not.

Would I write FFT myself? The answer to this is also probably not, as FFT has been implemented many times already. So chances are you will find some library that has FFT already implemented. Considering that C is a portable language whereas assembly is not, you will be far more likely to find existing libraries already implemented in C.

If you want the most extreme possible performance, you could obviously hand-tune a FFT algorithm to work as quickly as possible in assembly language. But I don't really believe it makes sense to do that except in very exceptional circumstances.

Answer 8

My own view FWIW is that any time you want maximum speed/efficiency/throughput/whatever, assembler is your friend, so long as you are proficient. A compiler is dumb; it "knows" only what its author thought to program into it, and its author did not know your application at all.

I must admit, I have loved assembler since early 80s 8 bit micros (not dissimilar at all to modern MCUs in many respects) where learning "machine code" was a prerequisite for getting any useful performance out of them, but I think its role remains as the way to program for maximum efficiency. Plus, it is highly rewarding as you can throw in all kinds of optimising shortcuts that a compiler won't think of, because a compiler can't think at all.

C is okay I guess. But if you really know what you want your machine to do at the hardware level, go assembler.