Following on from my earlier post about the restrict keyword, I’d like to try and dispell the myth around the volatile keyword. The meaning of volatile is a popular interview question, particularly for embedded development jobs and I’ve heard some programmers describe the properties of this keyword as if it had super powers.
The volatile keyword does a very simple job. When a variable is marked as volatile, the programmer is instructing the compiler not to cache this variable in a register but instead to read the value of the variable from memory each and every time the variable is used. That’s it – simple isn’t it?
To illustrate the use of the keyword, consider the following example:volatile int* vp = SOME_REGISTER_ADDRESS;
for(int i=0; i<100; i++)
In this simple example, the pointer vp points to a volatile int. The value of this int is read from memory for each loop iteration. If volatile was not specified then it is likely that the compiler would generate optimized code which would read the value of the int once, temporarily store this in a register and then use the register copy during each iteration.
Examples of where volatile is often used:
- When accessing hardware registers via pointers. It is necessary for the generated code to always access the hardware registers value and never a potentially out of date copy.
- When accessing a variable that is shared between two or more threads or between a thread and an ISR.
Common myths about the volatile keyword:
- A volatile variable will never reside in cache memory – e.g. within the L2 cache of a processor. This is not true. In the case where the volatile variable is shared between two software threads, it is highly likely that the variable will exist in cached memory and the cache coherency policy will ensure that the threads will see the correct and up-to-date value of the variable in the event that the threads are running on seperate cores that don’t share the same cache. When the volatile variable refers to a hardware register, it is likely that the memory map of the system will be setup such that this register is not cacheable in the processor cache, but this is setup and managed by the appropriate device driver and is not something that is provided by the volatile keyword.
Thats’ it. So the next time you hear somebody waxing lyrical about the super powers of the volatile keyword, please feel empowered to enlighten them!
I was pleasently surprised to encounter a C keyword that I had never heard of before. The keyword in question is the
restrict keyword which is a type qualifier for pointers and is a formal part of the C99 standard. This keyword allows programmers to declare that pointers which share the same type do not alias each other. This information can then be used by the compiler to make optimizations when using the pointers. If the data is in fact aliased, the results are undefined.
Consider the following example:
memcpy((void* restrict) dst, (void* restrict) src, size);
This tells the compiler that neither the
src pointer paramters overlap and so the compiler is free to apply any optimizations – including optimizations that may result in out of order reads/writes.
Mainstream compilers have varying support for this feature.
- GCC supports it in C99 mode – specified via the “-std=c99” option or for non-C99 code by specifying
__restrict to enable the keyword as a GCC extension.
- Microsoft’s Visual Studio .NET 2005/2008 compiler doesn’t support this feature as specified in the C99 standard but does provide similar support using the
__restrict specifier. Micorosft also allows this keyword to be specified for both C and C++ code. See the MSDN documentation for more details on Microsofts implementation and differences between it’s support and the C99 specification of
Finally, it should be noted that this keyword is specific to C and is not specified in the 1998 C++ specification nor is it currently planned for inclusion in the fothcoming C++ specification update.
This blog has moved from it’s old home at http://stephendoyle.blogspot.com to its own domain at http://softwareramblings.com. The move should be transparent to subscribers of the feedburner feed – at most there will be a few duplicate entries in the feed as the old posts are imported into the new setup.
So why the move? The main reason was because I found the blogger interface a bit cumbersome for posts that involved source code. I was underwhelmed by the presentation of source code that resulted from <code> and <pre> tags. It was also a pain to have to remember to properly handle the angle brackets and ampersands in the code. I decided to move from blogger to WordPress so that I could take advantage of it’s syntax highlighting plugin which is based on the syntaxhighlighter Google Code project by Alex Gorbatchev. Check out the following snippet – cool or what?
using namespace std;
cout << "Hello World" << endl;
Rather than moving the blog from stephendoyle.blogspot.com to something like stephendoyle.wordpress.com or softwareramblings.wordpress.com I decided to move the blog to it's own domain. Since the blog was entitled "Software Ramblings" and the domain of the same name was miraculously free, my mind was made up.