Open Source DSP XOs

[abraxalito]

Cortex M0 assembler I predict is going to become the world's most portable computer language ever, in terms of the number of platforms that will run it natively.

[steph_tsf]

Originally Posted by abraxalito

Cortex M0 assembler I predict is going to become the world's most portable computer language ever, in terms of the number of platforms that will run it natively.

I guess you want bare metal programming, and for this you think you need to code in assembly. There is another way to do it. You may use the C language in a very restrictive way only using interger arithmetics, integer arrays, no characters, define most variables as public, define a few counters and flags as "register" (if your C compiler doesn't ignore such directive), only use simple control flow (if-then-else, switch, do while, break, goto), avoid calling functions so prefear storing the result of evaluations in dedicated variables, be cautious with pointers and structures (check the code generated by your compiler), and last but not least, avoid all input and output features, and avoid all unix/linux system interfaces. This way, you could generate efficient, readable, maintenable and portable code for the Cortex-M0/1/3/4 family. On top of this you would use assembler for your IIRs and FIRs, using different macros depending on the Cortex version you are running, finely tuned to the Cortex version you are running.

[abraxalito]

Originally Posted by steph_tsf

I guess you want bare metal programming, and for this you think you need to code in assembly.

The reason I want bare metal programming is because its such fun. So having fun programming is the primary metric to optimise, in my experience the most fun is to be had with tight hand-coding and optimizing every cycle, knowing all the quirks of the hardware and working around or in step with them. In contrast C programmers are at the mercy of their compiler and its ability to optimize and have little need to know machine specifics. If I wrote in C I'd be mulling over the machine code it generated anyway and wondering why it was idiotic in its use of resources. So why not just take the (to me unnecessary) abstraction layer out of the way from the start?

C coding certainly has its place, tiny, ultra-low power systems with heavily limited resources isn't one of them in my estimation.

[chris719]

My point was only that in most cases you can implement the same function in C in less time.

If you really enjoy writing in assembler then sure, but I don't know many people who do.

C is heavily used in automotive and implantable medical devices. Assembler is difficult to maintain, error prone, gives you no ability to do static analysis and makes unit testing more difficult.

[steph_tsf]

Originally Posted by abraxalito

The reason I want bare metal programming is because its such fun. In contrast C programmers are at the mercy of their compiler and its ability to optimize and have little need to know machine specifics. So why not just take the (to me unnecessary) abstraction layer out of the way from the start?

Try the datacom bitbang scheme as an example. Where do you see an "abstraction layer" if you code it in a very restrictive C like described above ? I think that you would have fun coding the datacom bitbang using such restrictive C. I think that initially, you rejected the bitbang datacom scheme because of the annoyance of coding it in assembly !

[abraxalito]

No, I rejected it initially not for the coding challenges (I enjoy them, provided the purpose is worthwhile) but for the apparent waste of CPU resources. When you presented your case in more detail then I noticed the 20 cycles you estimated was indeed fairly immaterial in the scheme of things.

[Trevor White]

Originally Posted by abraxalito

Cortex M0 assembler I predict is going to become the world's most portable computer language ever, in terms of the number of platforms that will run it natively.

good luck to you. Unless you know the processor inside out it will be hard to do a better job than an optimizing C compiler.

[abraxalito]

Its not merely the processor, its all the peripherals too. But yeah, my aim is to get to know them better than the compiler writer

[steph_tsf]

Originally Posted by abraxalito

Its not merely the processor, its all the peripherals too. But yeah, my aim is to get to know them better than the compiler writer

Agree, I/O and peripheral control are areas where handmade assembly code is generally overperforming C compiled code. Such handmade assembly code may deliver a ready-to-use 32-bit integer, to be accessed by the C compiler. This way you may combine the advantages of both worlds.

[rsdio]

I disagree with the claim that assembly programming is a waste of time.

In my experience, a mix of C and assembly is most beneficial. Interrupt routines, FFT, and other DSP should generally be coded in assembly, unless you already have an efficient API from the chip manufacturer. The high-level program flow logic can be in C because it is not usually time-critical.

Originally Posted by Trevor White

assembler is not portable whereas C usually is.

Interrupt routines are not portable, because they are highly dependent upon the specific peripherals that they are servicing.

As for FFT or other serious DSP subroutines, if you're coding in C for portability then you probably are not using your processor very efficiently.

Companies like Texas Instruments have entire documents devoted to the subset of C that you need to use to take advantage of special addressing modes, bit reversal, and other constructs that are common to DSP but simply not able to be expressed in C. If you want to code those sorts of things in C and place copious comments warning maintainers not to change a single character, then proceed at your own risk. It's not going to be portable anyway, although it might work with a slightly different processor that uses the same compiler.

I'm speaking primarily of actual DSP chips, rather than general purpose processors. However, every processor that I've studied seems to have a few instructions that are useful for speeding things up in ways that the compiler usually misses. This is particularly true for vector processing and other DSP-related tasks.

In general, embedded firmware is not portable. I actually think that it's a mistake to code embedded firmware using techniques that are aimed at portability rather than optimization.