>If that's the case the whole thing becomes a game of figuring out what optimisations the compiler does make, and doing the rest yourself.
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 think I'd probably prefer working with either ARM or MIPS assembly over x86, except for the lack of some of x86's built-in arithmetic instructions (like divide). As long as you've got an instruction set reference card handy (preferably in PDF format), it's not too difficult to work with any assembly language (I've done debugging in ARM and x86, took a class on MIPS, and wrote entire firmwares in 8-bit PIC assembly).
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.
Really? He tested and measured a few different approaches. Do you think he's advocating just using his approaches without measurement?
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.
> I'd say most of this stuff is written for people who wouldn't really learn much from a disassembly.
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.
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.