Writing Efficient C Code for Embedded Systems

       By Hai Shalom 

 原文链接: http://www.rt-embedded.com/blog/archives/writing-efficient-c-code-for-embedded-systems/

The traditional definition of efficiency has two aspects: speed and size. In most cases, optimizing the first aspect causes a degradation in the other, and it’s a matter of balancing between the two, according to the specific needs. Per each embedded system, or even a software module, the appropriate strategy must be balanced between the two. Nowadays, there is a new dimension to this definition; power. In this article, I am going to discuss about the traditional aspects. In the years I’ve been working as a software engineer, I gained a lot of experience about C code efficiency. I saw how changing a few lines of code makes the difference, either in performance, final size or memory consumption. The examples I’ll show here were written in C and tested on an ARM platform. You should expect similar behavior by other processors. I might update this article from time to time with some more tips, so it is recommended to bookmark it and catch up.

Global variables

The use of global variables is not recommended in most cases, but there are cases where we must use them. In some cases, we declare large tables/arrays which are used later by the software. When using global variables, follow the following guidelines:

• Tables/Arrays which never change, should be defined as  const. When defining them as constant, they will be moved to the code section. If this table/array was defined in a shared library, without the const directive, the table would be copied per each instance of a linked process. However, with the const directive, it will have only a single instance in memory.
• Reading and writing global variables require additional opcodes (load the global address, load the value from the address, and then store the value back). If possible, try to use local variables, or use a  local copy.
• Declare all globals as  static, unless other C files need to see them (not recommended at all. You can use a local read and write functions instead, and keep them static).

Variable types, signess and localization

In is very important to select the appropriate variable types you are using. There are a few rules of thumb in this case:

• Try to use variables in the native size of the processor (like  int for 32-bit processors). For a typical 32-bit processor, the use of  short int or  char types is less recommended. There are processors which need to read a 32-bit word anyway and do some shifting and masking, just to get the right value. Other pipeline processors which have 16-bit or 8-bit access opcodes, may read 32-bit anyway.
• If you don’t require negative values, use  unsigned variables. Unsigned variables yield  better performance, especially when using division and multiplications.
• Declare variables  only when you really need them and not in the begining of the function. This will allow the compiler to better utilize the internal registers and avoiding assignment of a register to a variable which is used only later.

Division and Modulus

The division and modulus arithmetic operations require extensive CPU cycles. In ARM platform, they are done by software, and it is also known that in other processors, these operations are much slower than any other arithmetic operations.

The modulus operation can be implemented much more efficiently, in some cases, using a simply counter:

// Bad example:
int tick_after_100_cycles_mod( void )
{
    static unsigned int i = 0;

    if( i % 100 == 0) {
        return 1;
    } else {
        i++;
    }

    return 0;
}

// Good example:
int tick_after_100_cycles_cnt(
    void )
{
    static unsigned int i = 0;

    if( i >= 100) {
        return 1;
    } else {
        i++;
    }

    return 0;
}

The division operation is extremely efficient if the divider is a natural number in power of two (2,4,8,16,32…). The reason for this is the binary representation of the numbers inside the processor, where each division by two equals to a single right shift. In this case, if you are dividing a variable with a hard coded value in the power of two, the compiler will automatically convert it to a shift operation. In case you are dividing by a variable, the compiler can not know what values could be used in it and will not optimize this division, so you’ll have to help it by doing the shift operation manually. Here are a few examples and the corresponding output for ARM:

/* Results in a call to division opcode or function */
int test_div( unsigned num, unsigned div )
{
    return num / div;
}

/* Results in an optimized automatic shift right */
int test_div_hardcoded_power_2( unsigned num )
{
    return num / 8;
}

/* Results in an optimized automatic shift */
int test_div_shift_right( unsigned num, unsigned powerof_two )
{
    return num >> powerof_two;
}

00000000 <test_div>:
   0:   e52de004        push    {lr}            ; (str lr, [sp, #-4]!)
   4:   e24dd004        sub     sp, sp, #4      ; 0x4
   8:   ebfffffe        bl      0 <__aeabi_uidiv>
   c:   e28dd004        add     sp, sp, #4      ; 0x4
  10:   e8bd8000        pop     {pc}

00000014 <test_div_hardcoded_power_2>:
  14:   e1a001a0        lsr     r0, r0, #3
  18:   e12fff1e        bx      lr

0000001c <test_div_shift_right>:
  1c:   e1a00130        lsr     r0, r0, r1
  20:   e12fff1e        bx      lr

We can see that the functions that use shift operation are very efficient, while the function with the real division calls the external__aeabi_uidiv( ) function to calculate the result.

For loops

For loops are widely used in the code. The natural human thinking makes us write our for loops from 0 to the maximum value. However, in case the order of the index is not important, it is more efficient to do the for loop from top to 0. The reason is due to an extra comparison opcode required when not comparing with 0. Per each incrementing for iteration, the CPU needs to check that we have reached the maximum value, and then break. However, if the for loop is decrementing, the comparison is not required because the result of the decrement action will trigger the Z (zero) flag, and the CPU will know when to break just by looking at it.

extern void foo( int );

void test_incrementing_for_loop( void )
{
    int i;

    for(i=0; i<100;i++) {
        foo(i);
    }
}

void test_decrementing_for_loop( void )
{
    int i;

    for(i=100; i; i--) {
        foo(i);
    }
}

00000000 <test_decrementing_for_loop>:
   0:   e92d4010        push    {r4, lr}
   4:   e3a00064        mov     r0, #100        ; 0x64
   8:   ebfffffe        bl      0 <foo>
   c:   e3a04063        mov     r4, #99 ; 0x63
  10:   e1a00004        mov     r0, r4
  14:   ebfffffe        bl      0 <foo>
  18:   e2544001        subs    r4, r4, #1      ; 0x1
  1c:   1afffffb        bne     10 <test_decrementing_for_loop+0x10>
  20:   e8bd8010        pop     {r4, pc}

00000024 <test_incrementing_for_loop>:
  24:   e92d4010        push    {r4, lr}
  28:   e3a00000        mov     r0, #0  ; 0x0
  2c:   ebfffffe        bl      0 <foo>
  30:   e3a04001        mov     r4, #1  ; 0x1
  34:   e1a00004        mov     r0, r4
  38:   e2844001        add     r4, r4, #1      ; 0x1
  3c:   ebfffffe        bl      0 <foo>
  40:   e3540064        cmp     r4, #100        ; 0x64
  44:   1afffffa        bne     34 <foo+0x34>
  48:   e8bd8010        pop     {r4, pc}

We can see that the decrementing for loop has one less opcode.

In some cases, when short loops are required, it could be more efficient (in terms of speed) to unroll the loop and save all the loop overhead. The compiler can be configured to do that automatically when using the -O3 optimization flag.

extern void foo( int );

void for_loop( void )
{
    int i;

    for(i=4; i; i--) {
        foo(i);
    }
}

void unrolled_loop( void )
{
    foo(4);
    foo(3);
    foo(2);
    foo(1);
    foo(0);
}

00000000 <unrolled_loop>:
   0:   e52de004        push    {lr}            ; (str lr, [sp, #-4]!)
   4:   e3a00004        mov     r0, #4  ; 0x4
   8:   e24dd004        sub     sp, sp, #4      ; 0x4
   c:   ebfffffe        bl      0 <foo>
  10:   e3a00003        mov     r0, #3  ; 0x3
  14:   ebfffffe        bl      0 <foo>
  18:   e3a00002        mov     r0, #2  ; 0x2
  1c:   ebfffffe        bl      0 <foo>
  20:   e3a00001        mov     r0, #1  ; 0x1
  24:   ebfffffe        bl      0 <foo>
  28:   e3a00000        mov     r0, #0  ; 0x0
  2c:   e28dd004        add     sp, sp, #4      ; 0x4
  30:   e49de004        pop     {lr}            ; (ldr lr, [sp], #4)
  34:   eafffffe        b       0 <foo>

00000038 <for_loop>:
  38:   e92d4010        push    {r4, lr}
  3c:   e3a00004        mov     r0, #4  ; 0x4
  40:   ebfffffe        bl      0 <foo>
  44:   e3a04003        mov     r4, #3  ; 0x3
  48:   e1a00004        mov     r0, r4
  4c:   ebfffffe        bl      0 <foo>
  50:   e2544001        subs    r4, r4, #1      ; 0x1
  54:   1afffffb        bne     48 <foo+0x48>
  58:   e8bd8010        pop     {r4, pc}

In the result we can see that the unrolled loop is longer. However, if we take a closer look, we can see that in the unrolled loop runs faster, because each iteration is done with 2 opcodes, compared to 4. In the unrolled for loop, we have 2 opcodes; loading a value and calling foo( ).In the regular for loop, we have 4 opcodes; loading a value, calling foo( ), reducing the register by 1 and comparing the result to 0 (with an incrementing for loop there could be even another opcode).

If-Else and Switch

In many cases, we use branching in our code. We all know the cases where we need to add some more conditions when the code grows or new features are added. We might end up with a multiple if-else-if-else clauses. Long if-else clauses are not efficient because for the worst case scenario, where the last comparison is positive, the CPU must check all other possibilities. In this case it is more efficient to use a switch clause which is implemented as a lookup table. The compiler generates a list of addresses and the CPU jumps directly to the correct one using the index in the switch.

If it is not possible to use switch, it may be possible to apply the binary search strategy. If the range is large, we can divide it to sub areas, and increase the performance by reducing the amount of tests in the worst case scenario.

/* Bad in worst case scenario */
if(i==1) {
    do_something1();
} else if(i==2) {
    do_something2();
} else if(i==3) {
    do_something3();
} else if(i==4) {
    do_something4();
} else if(i==5) {
    do_something5();
} else if(i==6) {
    do_something6();
} else if(i==7) {
    do_something7();
} else if(i==8) {
    do_something8();
}

/* Improved version */
if(i<=4) {
    if(i==1) {
        do_something1();
    } else if(i==2) {
        do_something2();
    } else if(i==3) {
        do_something3();
    } else if(i==4) {
        do_something4();
} else {
    if(i==5) {
        do_something5();
    } else if(i==6) {
        do_something6();
    } else if(i==7) {
        do_something7();
    } else if(i==8) {
        do_something8();
    }
}

We can see that for case i == 5, it takes 5 comparisons in version 1 and 2 comparisons in version 2, and in case i == 8, it takes 8 comparisons in version 1 and 5 comparisons in version 2. The binary break can be even finer if required.

Lazy Evaluation

Another principle in the if-else calculation of C is referred as “Lazy Evaluation“. In multiple conditional clauses, where there is a need to check various conditions, the generated code will evaluate only the minimum conditions which are required to satisfy the clause, from left to right. For example, in a multiple OR clause, it is sufficient that only one of the conditions becomes true to satisfy the clause, and in a multiple AND clause, it is sufficient that only on of the conditions become false to negate the clause. We can utilize this property to put the “easy” or “trivial” checks first, and thus avoiding some work.

int check_something_1( int i )
{
    if( i > 99 && i % 100 == 0 ) {
        return 1;
    }

    return 0;
}

int check_something_2( int i )
{
    if( i == 0 || i % 100 == 0 ) {
        return 1;
    }

    return 0;
}

In the first function, we first check if i is bigger than 99, and only then perform the modulus calculation. So actually, the modulus will be skipped every time we call this function with 0-99. In the second example, we will skip the modulus when i equals 0. In both cases, it would be wrong to switch between the conditions because the “easy” condition is first.

Return Value checking

Another thing that could slightly optimize the code is to check return values of functions by comparing to 0. Since comparison to zero is native to the CPU, it will usually save one or two opcodes. If a function returns 0 on success and -1 for failure, don’t check if the return value is -1. Instead, check if the return value is less than 0. Another example; If a function returns OK or NOK, compare the return value against the enumeration which is equal to 0.

/* returns 0 on success, -1 on failure */
extern int foo( int i );

/* Good example 1: Good path */
if( foo( 7 ) == 0 ) {
    /* Good path: do something */
}

/* Good example 2: Bad path */
if( foo( 7 ) != 0 ) {
    /* Bad path: do something */
}

/* Good example 3: Bad path */
if( foo( 7 ) < 0 ) {
    /* Bad path: do something */
}

/* Bad example */
if( foo( 7 ) == -1 ) {
    /* Bad path */
}

Lookup tables

Lookup tables can speed up the processing but increase the size by actually having all the answers in advance without the need to calculate them. Here’s an example that beats both size and speed:

char get_char( unsigned int i )
{
    switch(i) {
    case 0:
        return 'r';
    case 1:
        return 't';
    case 2:
        return '-';
    case 3:
        return 'e';
    case 4:
        return 'm';
    case 5:
        return 'b';
    default:
        return '\0';
    }
}

static const char lookup_table[] = { 'r', 't', '-', 'e','m','b' };

char get_char_lookup( unsigned int i )
{
    if(i>=sizeof(lookup_table)) {
        return '\0';
    }
    return lookup_table[i];
}

00000000 <get_char>:
   0:   e3500005        cmp     r0, #5  ; 0x5
   4:   979ff100        ldrls   pc, [pc, r0, lsl #2]
   8:   ea000005        b       24 <get_char+0x24>
   c:   0000002c        .word   0x0000002c
  10:   00000034        .word   0x00000034
  14:   0000003c        .word   0x0000003c
  18:   00000044        .word   0x00000044
  1c:   0000004c        .word   0x0000004c
  20:   00000054        .word   0x00000054
  24:   e3a00000        mov     r0, #0  ; 0x0
  28:   e12fff1e        bx      lr
  2c:   e3a00072        mov     r0, #114        ; 0x72
  30:   e12fff1e        bx      lr
  34:   e3a00074        mov     r0, #116        ; 0x74
  38:   e12fff1e        bx      lr
  3c:   e3a0002d        mov     r0, #45 ; 0x2d
  40:   e12fff1e        bx      lr
  44:   e3a00065        mov     r0, #101        ; 0x65
  48:   e12fff1e        bx      lr
  4c:   e3a0006d        mov     r0, #109        ; 0x6d
  50:   e12fff1e        bx      lr
  54:   e3a00062        mov     r0, #98 ; 0x62
  58:   e12fff1e        bx      lr

0000005c <get_char_lookup>:
  5c:   e3500005        cmp     r0, #5  ; 0x5
  60:   959f3008        ldrls   r3, [pc, #8]    ; 70 <get_char_lookup+0x14>
  64:   83a00000        movhi   r0, #0  ; 0x0
  68:   97d30000        ldrbls  r0, [r3, r0]
  6c:   e12fff1e        bx      lr
  70:   00000000        .word   0x00000000

We can see that the lookup table implementation is fast and small.

Data caching and avoiding calling other functions/system calls

My meaning here is not for the actual CPU cache. Sometimes, we call some functions or system calls in order to perform some calculation or get some data. If possible, try to reduce and eliminate the use of these, especially system calls which cause a context switch and data copying (relatively slow actions).

In this example, we can skip calling getpid( ) starting from the second time we call this function:

#include <unistd.h>
#include <stdlib.h>

pid_t my_getpid( void )
{
    pid_t pid = getpid();
    return pid;
}

pid_t my_getpid_optimized( void )
{
    static pid_t pid = -1;

    if(pid<0) {
         pid = getpid();
    }
    return pid;
}

00000000 <my_getpid_optimized>:
   0:   e92d4010        push    {r4, lr}
   4:   e59f4020        ldr     r4, [pc, #32]   ; 2c <my_getpid_optimized+0x2c>
   8:   e5943000        ldr     r3, [r4]
   c:   e3530000        cmp     r3, #0  ; 0x0
  10:   ba000001        blt     1c <my_getpid_optimized+0x1c>
  14:   e5940000        ldr     r0, [r4]
  18:   e8bd8010        pop     {r4, pc}
  1c:   ebfffffe        bl      0 <getpid>
  20:   e5840000        str     r0, [r4]
  24:   e5940000        ldr     r0, [r4]
  28:   e8bd8010        pop     {r4, pc}
  2c:   00000000        .word   0x00000000

00000030 <my_getpid>:
  30:   eafffffe        b       0 <getpid>

While the my_getpid( ) function looks a lot shorter (both in the code and in the assembly), it is actually much slower than the other function. The reason is because the my_getpid( ) function will initiate a system call each time it is called, and on the other hand, themy_getpid_optimized( ) function, will call the system call only once. The rest of the times will return the stored process id. In this example, we can see the tradeoff between speed and size.

Efficient search and sort functions

The uClibc library (and probably other standard C libraries) provide very efficient search and sort functions, so if you need to perform searches or sorts on any type of variable, you don’t need to write an algorithm from scratch, but use the existing ones. The binary search function is called bsearch( ), and the quick sort function is called qsort( ). When using these functions, you need to specify the size of your element, and a comparison function which will be used by the algorithms to perform their actions. Here’s an example for quick sorting an array of elements. The elements are made of an index and a name. We define the sort criteria as the index number, and write the comparison function accordingly.

#include <stdlib.h>

/* Entry element */
struct entry_t {
    int index;
    char name[ 10 ];
};

static int mycmp( const void *a, const void *b )
{
    /* Compare the elements by indexes */
    if(((struct entry_t *)a)->index == ((struct entry_t *)b)->index) {
        return 0;
    }
    return ((struct entry_t *)a)->index > ((struct entry_t *)b)->index;
}

/* Maximum elements */
#define MAX_ENTRIES 100

/* The array to be sorted */
struct entry_t entries_array[ MAX_ENTRIES ];

int do_sort( void )
{
    /* Sort the array */
    qsort( &entries_array, MAX_ENTRIES, sizeof( struct entry_t ), mycmp );
    return 0;
}

Inline functions

Inline functions are functions which are copied inside the calling function thus avoiding the function call overhead. It could be used to increase the performance of a specific critical area. Note that inlines create code duplication per each call to them, so use them wisely.

Bitmaps

A bitmap is usually a register (32-bit) variable that can represent data. The 32-bits can be divided to represent up to 32 pieces of data, wit 1 bit per piece which represent 2 states (on or off, enabled or disabled). The less data pieces represented, the more data can be saves (for 16 pieces, there are 2 bits which represent 4 different states). Sometimes bitmaps can be very efficient comparing to other data types, mainly because the single memory access, and the fact that data can be manipulated using bit-wise operations (&, |, ~, ^). For example, suppose we need to keep a list of objects (like interfaces, devices, etc.), and we want to keep track which of them has a specific property enabled (like, link, connectivity, etc.). Usually, we will use an array or any other data type to store this information. If the list is 32 entries long or less, we can store it in a register, and mark the property using a single bit. Each object will have its own offset in the register. Enabling a property is a single OR operation in the object’s offset, and disabling a property is a single AND operation in the object’s offset.

Compiler optimizations

Don’t forget to enable the appropriate compiler optimizations. You can read about it here

Resources

Quick sort: http://linux.die.net/man/3/qsort
Binary search: http://linux.die.net/man/3/bsearch
Using gcc: http://www.rt-embedded.com/blog/archives/using-gcc-part-2/

.