3 ms·
Even better rule: Know the limitations of your target processor and compiler and code accordingly. Example 1: Some (bad) compilers just ignore the const keywor
by __david__ 13y ago
Even better rule: Know the limitations of your target processor and compiler and code accordingly.
Example 1: Some (bad) compilers just ignore the const keyword (and therefore treat consts like normal variables). Use #defines with these compilers (or get a better compiler).
Example 2: Some (older, smaller) processors don't have an integer division instruction. Avoid division at all costs on these processors unless you are not worried about space or execution speed.
- Joeboy 13y ago> Example 2: Some (older, smaller) processors don't have an integer division instruction. Avoid division at all costs on these processors unless you are not worried about space or execution speed. Ok, so steer clear of division on ARM CPUs.
- zhemao 13y agoDepends on the ARM CPU. Some variants of ARMv7 architecture have an integer divide function. https://en.wikipedia.org/wiki/ARM_architecture#Arithmetic_instructions https://en.wikipedia.org/wiki/ARM_architecture#Arithmetic_in...
- __david__ 13y ago> Ok, so steer clear of division on ARM CPUs. Don't ignore the last part of the sentence: > …unless you are not worried about space or execution speed. I'd argue that on ARMs you're generally not worried about execution speed (as most run pretty fast nowadays), nor space (RAMs and flashes generally have lots of space). Now, do you have a really slow ARM, or are you running in a really constrained space (like a tiny metal-mask ROM)? Then yes, avoid it.
- twoodfin 13y agoSome (older, smaller) processors don't have an integer division instruction. Avoid division at all costs on these processors unless you are not worried about space or execution speed. ...unless you know your compiler is capable of converting the division into cheaper operations via strength reduction, per your well-considered rule.
- kps 13y ago… which will (normally) only happen if the dividend is unsigned. Another reason to prefer unsigned ints is that the C standards make signed overflow undefined. This is becoming increasingly important as code for embedded systems is built using ‘big’ optimizing compilers, rather than the simple ‘portable assemblers’ assumed by the old old rules of thumb like manually converting divides to shifts. “If you lie to the compiler, it will get its revenge.” — Henry Spencer
- nitrogen 13y agoAnother option is reciprocal multiplication, possibly with a larger integer type. Reciprocal multiplication is an important element of my software's ability to run a Kinect at ~30fps on an ARM cpu with no FPU and no division instruction.