[Stenzel]

Since you ask, I use lots of assembly level programming for digital audio signal processing. Some ARM instructions offer special DSP specific features like saturation and fractional arithmetic that have no equivalent int C, so it justifies using assembly. Smaller ARM cores without NEON offer some kind of miniature SIMD by operating on two 16-bit or four 8bit numbers, these can speed up things as well. To take full advantage of these it is best to write some portion of code in assembly. I usually wrap a processing sequence into a gcc-style inline assembly macro, this way I can easily compare with a C-only macro and maintain portability, and it saves me from having to deal with the complete instruction set and calling conventions.

[oriolid]

I've also been working with DSP processors in audio processing. The only time I've used actual inline assembly was storing stack pointer to measure stack usage.

For saturating arithmetic and other stuff we used compiler intrinsics, which freed us from handling register allocation, stack management etc by hand. On that processor there weren't special instructions for saturating arithmetic but a flag was used instead, the compiler also kept track of that one too.

We did read the assembly result and tweaked C code until assembly looked like what was expected, though.

[dmytrish]

Technically, assembly is not required for measuring stack: just use regular C address of any local variable/function argument (minus an address of some local variable in main) to have some approximation of stack usage.

[oriolid]

True. But I was young, stupid and had just completed a course on assembler on that processor. Money well spent.

[geokon]

Do you have any good examples?

It's something id like to try (however in c++) but I'm not sure how to do it in a smart/not-too-ugly way