Preprocessor -Coding myth 4

There is this classic case which came as a surprise to me when a fairly senior member of my team started arguing with me about a particular implementation that had made....below is the case

#define BusClock ((Crystal_Frequency)/(Prescalar))

Now the argument was ...why was i not calculating manually and typing in the values.
Our Dude Says >> See Macros will be just replaced by the compiler so when you load it into the register like this

BCLK = BusClock;

then there will be more run time due to the division of crystal freq by prescalar.
Well this is totally wrong. There are parts of the statement which are correct and which are wrong.
Correct parts >> Macro's will be dumbly replaced ( not by the compiler but by the preprocessor).
Which means that when my code goes to the compiler it looks like this

BCLK = 600000/12;
where cystal is 6Mhz and Prescalar is 12.
Does that mean it will go to the assembler in the same way....No!! and that is the wrong part.

As a part of basic optimization the compiler will be clever enough to do this division of 600000/12 and feed the appropriate value into BCLK. which means actually it looks like

BCLK = 50000;

before anything meaningful really begins.
In most compilers this cannot be turned off and is a basic optimisation. Infact, I have known a compiler that had a problem when we gave too big numbers. It would just give some gibberish error.

So the basic rule is that ...
If the compiler has all the information that it needs to create a single number ( after as many operations ...like 1+(10000)*12/(53) etc...) it will do it on its own to give a nearest number. Note that these divisions and multiplications are Integer unless you explicitly tell the compiler that they are double. So based on how you choose the values you might end up with varying results.

If anyone knows of a compiler that doesn't do that, please enlighten me...
Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.