Volatile : Demistyfied

  

Introduction
"Volatile" is a qualifier in 'C' which is applied to a variable when it is declared. So, what does it tells to the compiler? It gives the information to the compiler that the value of the variable may change at any time during the execution of the code without the knowledge of the compiler. If proper precautions are not taken, we might not get the desired results. A variable should be declared volatile whenever its value could change unexpectedly.

The syntax for declaring the variable as volatile is given below,

volatile dataTpye variable;  

Let us understand the “Volatile” keyword in deep through the following examples.

Example 1:

Let us consider small and simple example as shown in the Fig:1 to study the behavior of the 'volatile' keyword in C.

Fig 1: Code without the use of volatile.

In the above example the intention of the programmer is to keep polling inside the while loop until 'flag' value becomes 1(one).But the compiler, while compiling the code applies the optimization techniques and compiler will notice that no other code can possibly change the value stored in 'flag', and therefore assume that it will remain equal to 0(Zero) all times. The compiler will then replace the function body with an infinite loop as shown in the below Fig 2

                Fig 2: Optimization applied by the compiler to the code shown in fig1.

Let we check the size of the assembly code generated by the compiler as shown in the below Fig 3.

Fig 3: Size of assembly code generated by the compiler.

Now, if you observe Fig 3, the size can be found as 482 bytes in the 5^th column. Now, we will apply the volatile keyword to the flag variable to the code shown in Fig 1, as shown in the below Fig 4,

                 Fig 4: Code with volatile  

Let we check the size of the assembly code generated by the compiler as shown in the below Fig 5.

Fig5: Size of assembly code generated by the compiler after applying 'volatile' keyword.

Now, if you observe Fig 5, the size can be found as 501 bytes in the 5^th column. So, when we compare the sizes of both the codes with & without volatile keyword, obviously one can observe that the compiler is not optimizing the variable flag when it is qualified as “Volatile”.

Let we still experiment further to explore where the compiler is optimizing the code, to do this apply the vimdiff command to the assembly codes generated earlier, the difference is shown in the below fig 6:

Fig 6: Difference between the assemblies codes generated without & with volatile keyword.

From the above figure, we can conclude that volatile keyword prevents the application of optimization techniques by the compiler.

Example 2

Let us consider another example, where “for” loops are used commonly in the Embedded C code for the generation of the delays. Let us see how the compiler will optimize the code containing the “for” loops in the embedded C code without the use of the qualifier “Volatile” as shown in the Fig 7 below,

Fig7: For loop without volatile qualifier.

Let us generate the assembly code for the above given example, using the command given in the note 2, and getting the size of the assembly code using the “ls” command is given below in Fig 8,

Fig8: Size of assembly code generated by the compiler without volatile qualifier.

Now, we will apply the volatile keyword to the “i” variable in the code shown in Fig 7, as shown in the below Fig 9,

Fig9: Code with volatile keyword.

Let us generate the assembly code for the above given example, using the command given in the note 2, and getting the size of the assembly code using the “ls” command is given below in Fig 10,

Fig10: Size of assembly code generated by the compiler with volatile qualifier.

Comparing the sizes in the Fig 8 & 10, one can identify the compiler is applying the optimization techniques without the volatile qualifier. The dis-assembly code for both with & without volatile keyword is shown below in Fig  11,

Fig 11: Difference between the assemblies codes generated without & with volatile keyword.

Example 3 : Global variables accessed by multiple tasks within a multi-threaded application

Let us consider one more example to show how the global variable will be affected by the compiler optimization in the multi-threaded application. The example code snippet is shown as below in Fig 12,

Fig 12: Demo code to show how global variable will be affected in multi threaded program.

In the above demo program, the compiler doesn't have any knowledge of context switching between the two threads. If the compiler optimizations are turned “ON” then the compiler will assume that global_item_count variable is always “ZERO” and no other part of the thread is attempting to modify it. So, the compiler may replace the line no. 11 in the demo code like this

 

Which is nothing but the infinite loop, so in-order to avoid such optimizations by the compiler, it is safe to declare the variable global_item_count as “volatile”.

Similarly, one can realize the effect of producer-consumer problem accessing the global variable without declaring it as “Volatile”. Refer the link below

http://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem

Example 4: Interrupt service routines

Let us consider another example given in the fig 13, where “volatile” plays a very important role in the ISR.

Fig 13: Volatile keyword used in ISRs

In the above example, if the flag is not declared as “Volatile” , then the compiler may optimize the code assuming always the flag is ZERO and replace the while(!flag) to while(TRUE) in line no.11, which is nothing but infinite loop. But the flag value will change when the interrupt occurs.

Whether to declare the variable as 'Volatile' or not is cross compiler dependent, anyhow it is good practice to declare the variable as 'Volatile' to achieve the portability of the code.

Conclusion:

The main use of volatile keyword is to prevent compiler from optimizing the code in terms of time complexity by generating a code that uses CPU registers as faster ways to represent variables. By declaring the variable as “Volatile” forces compiled code to access the exact memory location in RAM on every access to the variable to get the latest value of it which may have been changed by another entity.

A variable should be declared volatile whenever its value could change unexpectedly. In real time, three types of variables could change,

1. Memory-mapped peripheral registers

2. Global variables modified by an interrupt service routine

3. Global variables accessed by multiple tasks within a multi-threaded application  

Emertxe-OSFY: Articles

Our Team from Emertxe consist of subject matter experts in specific areas (ex: Advanced C programming, Linux Kernel, Software Engineering etc..). This blog was initially created to share our knowledge with broader community, which we are expending further.

Open Source For You (OSFY) is India's top magazine on Open Source, promoted by Electronics For You (EFY) media. For the past couple of months we have been publishing our articles, now we have plans to continue publish articles on various topics. Here are the links to download PDF edition of these articles:

1. Bit-fields in C programming 

2. Open Source Software Engineering - An introduction to tools 

Mistake proofing in C programs

The Japanese concept of ‘poka-yoke’ talks about preventing mistakes by introducing certain mechanisms. It was originally designed for machinery which can be applied for any other aspect of life as well. What about mistake proofing in programming, especially with C programs? 

The earlier we get to know about mistakes in programs it is easier to fix them.

Let us consider the following code snippet (Fig 1): 

Fig 1: Simple if condition to check against MAX_VALUE

It is a simple conditional code where integer variable value is compared against absolute value MAX_VALUE and prints appropriate messages. While this appears to be a very simple program many times during development the equal-to operator (‘==’) is mistakenly replaced with assignment (‘=’) operator, which will yield unfavorable results (Fig 2): 

Fig 2: Small mistake giving incorrect results 

In this case message under if condition always will get printed irrespective of value of variable value.

Now how do we prevent this mistake? Very simple, change the way the equal-to operator is used (Fig 3). 

Fig 3: Mistake proofing during compile time

That way if assignment operator is used against an absolute lvalue, appropriate error message is given during compilation phase itself (Fig 4):

Fig 4: Error getting detected in compile time itself

By making such small changes in the code and making it as a programming practice, developers can avoid mistakes during programming which can be called as ‘poka yoke’. There could be many such examples that can be adopted for writing error free programs by getting issues earlier phase of development.

What other mistake proofing mechanisms you can think of? What other facilities that C offers for developers to operate in prevention mode? 

void pointers : Its Genericness

 

Void Pointers : Definition

Void pointers are the pointer variables which has no specific data type. These are also called as Generic pointers because it can point to any data type. In General, the compiler has no idea what type of object a void Pointer really points to.

Void Pointers : Declaration

A void pointer is declared like a normal pointer, using the keyword “void” as the pointer’s type as shown below,

Referencing & De-referencing the void pointers

In order to explain, how void pointers can be referenced & De-reference, let we take a small sample code as shown below in Fig 1,

 Fig 1: Referencing & De-referencing of the void pointers

From the above Fig 1, it is clear that while referencing the void * no need to typecast, only when De-referencing the void *, it need to be type-casted otherwise the gcc compiler will give warning along with error note as shown below in Fig 2,

Fig 2: Result obtained while de-referencing the void pointer without typecasting.

  Fig 3: Output after typecasting the void pointer while dereferencing.

Why void pointers are useful ?

One main advantage of using the void pointers is that it can be 're-usable'. Because of this feature of the void pointers 'space' & 'time' complexities can be reduced to some extent which is very critical in Embedded System designing.

They are very useful when you want a same pointer to point to data of different types at different times.

Let us consider a small simple code snippet, to show how void pointers can be re-usable which reduces the space complexity in the example as shown in the Fig 4 given below,

 

Fig 4: Void pointer reusability.

Fig 5: Output of the code shown in Fig 4.

For more clarity let us understand the above code through pictorial representation.

Line No.14 : The vptr is pointing to the address of the integer variable 'i', as shown below in Fig 6.1

Line No.18 : The vptr is pointing to the address of the character variable 'c', as shown below in Fig 6.2

Line No.22 : The vptr is pointing to the address of the float variable 'f', as shown below in Fig 6.3

Line No.26 : The vptr is pointing to the address of the double variable 'd', as shown below in Fig 6.4

Note : xxxx, yyyy, zzzz, aaaa, bbbb are all some arbitrary addresses shown in the above figures from 6.1 to 6.4.

From the figures 6.1 to 6.4 , it is very clear that we have used only one pointer i.e vptr , instead of four different pointers to point to four different variable of different data types, where space complexity is more. Only one thing that the programmer should keep in the mind while coding is that proper typecasting should be done depending on the different data types.

Void pointers are used in places where you need to work with different pointer types in the same code. One commonly used example is the library function qsort:

base is the address of an array, nmemb is the number of elements in the array, size is the size of each element, and compar is a pointer to a function that compares two elements of the array.

Pointer Arithmetic on Void*

Let us learn how to apply pointer arithmetic on the void pointers through the bug code as shown in the Fig 7 given below.

 

Fig 7: Bug code

Fig 8: Output of the bug code shown in Fig 7

From the above result, one can see that we are not getting the expected output. Surprisingly what went wrong ? Let us analyze the above code & output we got.

1. From the output it is very clear that addresses are incremented by one one byte, this is because the gcc compiler assumes sizeof(void) is 1 byte long.

2. So, when we increment void pointer by one, it is incremented by one byte long as one can observe this from the Fig 8(address part).

3. Now coming to the value part, the first value i.e arr[0] is getting printed correct, but after that all the values are wrong, this I am explaining through the pictorial representation as shown in the Fig 9

to Fig 13 below.

Note : The output depends on the endianness of the architecture.

Fig 9

Fig 10

Fig 11

Fig 12

Fig 13

From the above five figures, we can see why we are not getting the expected output. So the corrected code along with expected output is shown in the Fig 14 & 15 given below,

Fig 14 : Correction to the code given in Fig 7

Fig 15: Expected output for the code given in Fig 11.

void pointers can be assigned to any pointer value. One cannot dereference a void pointer without proper typecasting. Functions such as malloc, calloc, free utilize void pointers.

Pit-falls of Bit-fields

In the past few posts we have been checking various aspects related to bit fields. In this blog, let we focus on how bit-lengths will pose a serious issue to achieve portability in case of bit-fields structures.

Portability is basically about having the same program or application running across various processor architecture. When it comes to embedded systems portability plays a very important role as they have diversified set of hardware. 


To start with, let us take a simple program as given below in Fig 1:

Fig 1: Bit-length pose and portability issue. 

 

After running the above code, output is shown in the given below Fig 2:

Note: source code is tested under gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 version.

 Fig 2: Output of the source code given in Fig 1.

From the above figure 2, it is clear that when we declare the bit-length more than the sizeof(int)[ In our case , it is 4 bytes] , which is compiler dependent we are getting the error at the compile time. The above code perfectly works fine , if the machine WORD size is 64 bits, but fails to work with lower WORD size, which results in portability issue.

Pointers & Bit-fields

I want to focus on one more problem, why pointers cannot be applied for the bit-fields.let me practically explain this problem by taking an example shown in the fig 3 below,

Fig 3: Pointer operation and bit fields

The output of the above source code is given below,

 Fig 4: Output of the source code shown in fig 3.

One can observe from the above fig 4, when tried to reference the bit-field structure variable, compiler is generating an error, this is because direct addressing of the bit-fields structure variables is not possible in C, since the smallest unit of addressable memory in C is a sizeof(char) i.e byte addressable not an bit addressable. This is one of the pit-fall of the bit-field structure in C programming.

From the above two examples, we can conclude that how portability issue is major concern with the bit-fields, and also we saw direct addressing of the bit-fields is not possible in C programming. Apart from this two issues, even sizeof() operator cannot also be applied for the bit-fields since sizeof always returns size in bytes not in terms of bits. Use bit-wise operators instead, they are 100% safe and portable.

Face-off with sizeof()

sizeof : Brief

The unary operator sizeof is used to calculate the size of any datatype, measured in the number of bytes required to represent the type. The result of sizeof is the size of the type of the expression or parenthesized type-specifier that it precedes, and has an unsigned integral type which is usually denoted by size_t ( From Wiki ).

The sizeof() operator behaves differently in comparison with other operators. In this blog let us call out some of the uniqueness of this operator by taking two real time programming examples. The first one is about compile time behavior and second one is during run time behavior.

Case 1: Compile time behavior 

To start with, let us consider the simple code (Fig 1 below):

Fig 1: Sample program to demonstrate the sizeof() operator

Can you guess what would be the output of the above mentioned program? By first look anybody would say it as 4 (Assuming the sizeof(int) is 4 bytes) & 11. But, when I run the program in my system, it is showing 4 & 10 (ref: Fig 2 below)

Fig 2: Output

Why are we getting the value of variable ‘i’ as 10 instead of 11? Here is the reason:

1. Sizeof operator is the only operator in C, which is evaluated at the compile time. Where sizeof(i++) is replaced the value 4.
2. One can observe this, shown in the figure given below(inside the box), which contains the assembly code equivalent to the statement in C.

Fig 3: Assembly code generated by the compiler.

Note:

To obtain the assembly code as shown in Fig 3, follow the below given steps.

+ gcc -g filename.c ( In our case sizeof_run.c)

+ objdump -S output_file ( In our case a.out)

From the above figure, one can see that the sizeof() is completely evaluated at the compile time. And the whole sizeof(i++) is replaced by the constant value 4. so, there is no assembly code for i++ at all, which is to be evaluated at the run-time.

Case 2: Run- time behavior

As, I told before Sizeof() operator is the only operator in C, which is evaluated at the compile time.But, there is an exception for this in C99 standards, for variable length arrays.

To start with, Let us consider an code snippet shown below,

Fig 4: Code containing variable length array

Let us see the output, when the above code is compiled & run ( shown in fig 5 below)

Fig 5: Output of the sizeof_run.c

From the above output it is very clear that sizeof() operator is evaluated at the run-time, One can observe the equivalent assembly code generated by the compiler as shown in the Fig 6 given below.

Also, see the difference between the assembly code in the Fig 3 & Fig 6.

Fig 6: Assembly code generated by the compiler, for variable length array.

According to the C99 standards, the sizeof() operator yields the size (in integer bytes) of its operand, which may be an expression or the parenthesized name of a type. If the type of the operand is a variable length array type, the operand is evaluated at run time; otherwise, the operand is not evaluated and the result is an integer constant, during the compile time itself.

In the next blog we will see,

1. Need of sizeof().

2. Cases where sizeof() will not work.

3. How sizeof() is different from function call.