You just described much of embedded programming there.

>This is cargo cult optimisation of the worst kind.

Really? He tested and measured a few different approaches. Do you think he's advocating just using his approaches without measurement?

>no disassembly in sight, and no mention from which operations the division is synthesized

I'd say most of this stuff is written for people who wouldn't really learn much from a disassembly. They may work with 3-5 different families of chips, all with very different (and sometimes moderately strange) instruction sets. They mostly chose the chip due to cost or power consumption, and it's a tiny tiny portion of their design. They're trained in EE, not programming, and do enough to get through their design.

Debugging arm or mips assembler is considerably different than x86.

I was hunting through disassembled ARM code for performance bottlenecks and managed to speed things up quite a bit by manually removing divides that should've been caught by the optimizer from my C code. I didn't find it any more or less difficult than any other assembly language.

The problem, to me, is that he's not explained why the faster versions are faster (we don't know, because there's no disassembly), and the whole thing isn't reproducible because we don't know which compilers were used. For all we know, another compiler does better with the "slower" code.

They're trained in EE, not programming, and do enough to get through their design.

My EE friends definitely know assembly language. They also know that many chips don't have divide instructions, and at the very least, that the compiler can use other ops to work around that. Even for EEs who don't know, I don't think showing them the decomposition of the division would make their brains explode.

Debugging arm or mips assembler is considerably different than x86.

[citation needed]. I'll admit I've not done any work with MIPS, but I didn't have any trouble with ARM. Sure, there's Thumb mode, but that's pretty much it.

Even so, I find that a lot of the advice is misleading. As mentioned elsewhere, the reason modulus is slow is not that you can write it three arithmetic operations, but because division is slow. And especiall any kind of 32bit arithmetic on 8bit and 16bit processors. Even though he used narrower integer types, he did not explain why that was better.

gcc supports all three CPUs listed in that article.

Additionally, the manufactures compilers are often setup inside crappy IDEs with integrated debuggers. IAR was included with at least the middle chip he's talking about. The people doing this aren't necessarily the type of folks who use vim + gcc + unix command line stuff to get them onto the boards.

Why do they do this instead of using gcc? No clue. Probably they think they can make more money or are afraid of china stealing their silicon (seriously).