Which compiler, among those still used in 2014, does not convert a division by 2 into a shift?
But there are lots of oddball compilers for CPUs, DSPs, and other embedded quasi processors you've never heard of. Many don't really optimise at all.
A right shift of a signed, negative value is implementation-defined (which means, something in particular happens, and the compiler or its documentation is supposed to tell you what).
A left shift of a signed value is undefined (which means, the compiler is allowed to launch the missiles, or fail to launch the missiles, whichever is worse for you) if a nonzero bit could conceivable get into the sign.
Quote:Better Rule: Use whatever comparison operator is easiest to read in a given situation.
One of the very best things any embedded programmer can do is to make their code as readable as possible to as broad an audience as possible.
#1: Avoiding shifting versus doing division: Nope. Crappy compilers and bad architectures will yield bad results. Know what you're doing.
#2: Use a typedef instead of a bare C type, then. Also, on many systems space is king (the last embedded system I wrote had 6 bytes left over in code space, and 16-bit operations were incredibly expensive and nearly unaffordable).
#3: Just make the code clear. This rule is lunacy.
#4: Well, maybe. Except that variable initialization can often be made quite compact by the runtime (e.g., an expansion of a compressed data segment into RAM), and so save you code space.
#5: Again, the compiler can screw you here. Also, it's possible to take the address of a constant and have it be wiped out (for naïve implementations, anyway).
My basic rules:
#0: Don't make assumptions. Know what the heck is going on, fractally. Look at the generated code.
#1: Be a responsible engineer. Design and code for production and testing, and for the next guy. This often means not being clever, but if you are being clever, be forthright about it and don't leave your brilliance as a puzzle. (Don't be clever just to be clever. That will get you fired, no foolin').
#2: Avoid platitudes. Be wary of people who tell you not to use something, always, or to use a particular contruct, always. Be suspicious of code that follows someone else's dogma. [I once worked with a code base where the engineer had used the ternary -- "?:" -- operator everywhere because he thought it was more efficient than using 'if'. Of course it was just guesswork on his part and not only was his code a train wreck, but he had never measured his results. We fired that guy).
Embedded systems are just software, they're not magical, they're not (usually) that hard, and for some reason people are afraid of them. Some of my best moments in the industry have been writing these little things, they're fun as hell.