Inlining code - Coding Myth 2

This post is regarding the inline keyword.
Very often we learn C & C++ together and end up mixing one language with the other. I learnt this the hard way when i found out in some debate that the "inline" keyword doesn't belong to the C language.....Boohooo!!..
Inline keyword natively belongs to C++.  It serves the purpose of just ensuring that the function is pasted inline instead of having a call to the function at every instance of the function call.
It was not a part of C. In "C" we achive similar functionality by using what are termed as "Function Like Macro's".
E.g.
#define Max(a,b)  ((a)>(b)?(a):(b))
The funciton like macros have a major disadvantage over Inline functions and that is the blindness to the compiler.
#define macro's are processed by what is known as the "C Preprocessor". The preprocessor looks for the macros and does a macro pasting operation. Which means that where ever in the above example Max is used the equivalent code is pasted.
E.g
y = Max(5,6); is equivalent to y = ((5)>(6)?(5):(6));
Then what is this blindness funda?
Well if iwrote this code
int *ptr;
y = Max(ptr,'5').
Then even this would work as for the Macro-Processor. Infact in this particular example even the compiler will not complain. However, if this was a inline function then the compiler would have been flag an error.  So it is easy to see that the inline key word has benifits over the #define macro.
Now some interesting stuff

• - Did you know that the inline keyword is just a request to the compiler. The compiler might choose to ignore you fully and would just make the function a normal function if it feels that by making it inline it is losing out on optimization.This is in contrast with #define function like macro's which are outside of the compiler's control.
  

• - Modern C compilers provide you various methods of inlining function by compiler extensions. E.g some compilers provide pragma's

#pragma InlineStart
void Inlinefunction(void)
#pragma InlineEnd
or things like
@inline void Inlinefunction(void)

• Inlining is very useful to ensure modularity & keep your code clean. However, In "C" if this was natively available then we embedded users would not have resorted to function like macro's.
• Evils of the keyword "inline".....Well it is difficult to debug your inline function because there is no call to the function and also it is not really visible to your debugger:-(.
  

Now that we have some idea of the keyword "Inline", you can try to check out the statements made above using our good old GCC compiler with "-S" option and have a look at the generated assembly code.
Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

When Size does matter - Coding Myth 1

Again i am slow in updating this blog and this time it is really because I was busy with some GUI building activity on Matlab. I will write more about in another post. However, today the topic is more about "C" coding myths.

Some dudes I have met write really write complicated code like the one below stating that it will be more efficient. Some how they seem to feel that compact code ( in terms of number of lines & characters used) translates directly into lesser code volume in the microcontroller. I just tried this....

Code:

unsigned char alt2(void)
{
    unsigned char var=10;
    unsigned char output;
    if(var==1)
        output=3;
    else if(var==2)
        output = 2;
    else
        output =1;
    return output;       
}
unsigned char Alt(void)
{
    unsigned char var= 10;
    unsigned char output;
    output = (var==1)?(3):((var==2)?(2):(1));
    return output;
}
void main(void)
{
    int x;
    x = alt();
    x = alt2();
}
Now on compiling this with avr-gcc with -S option you should be able to get the assembly code output also. Let us compare the functions Alt and Alt2 which have same functionalities.
alt2:
    push r29
    push r28
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 2 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    brne .L2
    ldi r24,lo8(3)
    std Y+1,r24
    rjmp .L3
.L2:
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L4
    ldi r24,lo8(2)
    std Y+1,r24
    rjmp .L3
.L4:
    ldi r24,lo8(1)
    std Y+1,r24
.L3:
    ldd r24,Y+1
/* epilogue start */
Alt2 takes a stack frame of 2 bytes and the code is readable to a great extent. I am sure it is more maintainable compared to Alt. However, Alt generates a stack frame of 4 bytes.
Alt:
    push r29
    push r28
    rcall .
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 4 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    breq .L7
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L8
    ldi r24,lo8(2)
    std Y+3,r24
    rjmp .L9
.L8:
    ldi r24,lo8(1)
    std Y+3,r24
.L9:
    ldd r24,Y+3
    std Y+4,r24
    rjmp .L10
.L7:
    ldi r24,lo8(3)
    std Y+4,r24
.L10:
    ldd r24,Y+4
    std Y+1,r24
    ldd r24,Y+1

We see that now the stack frame is 4 bytes & to  add to the woes the code is not so much readable as well.
Thus, we break a myth that complicated & compressed "C" files give compressed code. More often that not modern compilers are clever enough to do everything that is needed for optimisation. So please spare yourself the troubel and let the compiler do its job.
However, that doesn't mean that we should write inefficient code. What it means is that -  "Dont think you have optimized the code by just changing some "if" statements to "ternary"  operators. It is more than that and quite usually compiler dependent". The best way to optimize is to read the compiler manual and try to understand the compiler and its capability. Then you can use tricks in "C" to optimize the code.
 

Powered by ScribeFire.

Thin in In

I am not putting up too much except this link. It talks about a new age of speakers which use thin films. This means that you can really get rid of those huge speaker boxes. As before it is sometime before one can see these in production.

Wanna
add your point or provide more info ? Please leave your comment. You
can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.