Tips and Tricks

Improve volatile Usage with volatile_load() and volatile_store()

Updated: 20190322

A C++ proposal for deprecating the volatile keyword has surfaced. This may surprise our readers, because as Michael Caisse said, "volatile is the embedded keyword."

The original intent of the volatile keyword in C89 is to suppress read/write optimizations:

No cacheing through this lvalue: each operation in the abstract semantics must be performed (that is, no cacheing assumptions may be made, since the location is not guaranteed to contain any previous value). In the absence of this qualifier, the contents of the designated location may be assumed to be unchanged except for possible aliasing.

The problem with its use in C++ is that the meaning is much less clear, as it is mentioned 322 times in the C++17 draft of the C++ Standard.

One problematic and common assumption is that volatile is equivalent to "atomic". This is not the case. All the volatile keyword denotes is that the variable may be modified externally, and thus reads/writes cannot be optimized. This means that the volatile keyword only has a meaningful impact on load and store operations.

Where programmers run into trouble is using volatile variables in a read-modify-write operation, such as with the increment (++) and decrement (--) operators. Such operations create a potential for a non-obvious race condition, depending on how the operation is implemented in the compiler and platform.

volatile int i = 2; //probably atomic
i++; //not atomic ...

Other problematic volatile use cases can be found, such as chained assignments of volatile values:

// is b re-read before storing the value to a, or not?
a = b = c

We recommend using volatile_load<T>() and volatile_store<T>() template functions to encourage better volatile behavior in our programs.

auto r = volatile_load(&i);
volatile_store(&i, r);

You can use these functions to refactor your programs and control volatile use cases. While this implementation does not meet the proposed specification, it's a step toward cleaning up our use of the volatile keyword.

#include <cassert>
#include <type_traits>

/** Read from a volatile variable
 * @tparam TType the type of the variable. This will be deduced by the compiler.
 * @note TType shall satisfy the requirements of TrivallyCopyable.
 * @param target The pointer to the volatile variable to read from.
 * @returns the value of the volatile variable.
template<typename TType>
constexpr inline TType volatile_load(const TType* target)
        "Volatile load can only be used with trivially copiable types");
    return *static_cast<const volatile TType*>(target);

/** Write to a volatile variable
 * Causes the value of `*target` to be overwritten with `value`.
 * @tparam TType the type of the variable. This will be deduced by the compiler.
 * @note TType shall satisfy the requirements of TrivallyCopyable.
 * @param target The pointer to the volatile variable to update.
 * @param value The new value for the volatile variable.
template<typename TType>
inline void volatile_store(TType* target, TType value)
        "Volatile store can only be used with trivially copiable types");
    *static_cast<volatile TType*>(target) = value;

As Odin Holmes pointed out in the comments, refactoring our code to use volatile_load() and volatile_store() can also boost the performance of our programs. This is because we are constraining the optimizer more clearly.

This traditional volatile code:

volatile uint32_t* register_x;
* register_x &= ~mask;
* register_x |= value;

Will not be as performant as this version:

auto r = volatile_load(&register_x);
r &=~mask;
r |= value;
volatile_store(&register_x, r);

Further Reading

Change Log

  • 20190322:
    • Added comments from Odin Holmes regarding optimizations.

Simple Fixed-Point Conversion in C

Operating on fixed-point numbers is a common embedded systems task. Our microcontrollers may not have floating-point support, our sensors may provide data in fixed-point formats, or we may want to use fixed-point mathematics control a value's range and precision.

There numerous fixed-point mathematics libraries around the internet, such as fixed_point or the Compositional Numeric Library for C++. If you are looking for a reliable solution to utilize long-term, spend some time to review these libraries to identify candidates for integration.

However, we don't always have the time required to select a library. Perhaps you just need to convert a fixed-point number for prototyping purposes, or you need to do a quick implementation for Friday's demo.

Below is a quick-and-dirty approach for converting between fixed-point and floating-point numbers. If you need to handle mathematical operations on fixed-point numbers, look for a library to integrate.

Lossy Conversion of Fixed-Point Numbers

First, we need to select our fixed-point type. For this example, we'll be using 16-bit fixed point numbers, in an 11.5 format (11 integral bits, 5 fractional bits):

/// Fixed-point Format: 11.5 (16-bit)
typedef uint16_t fixed_point_t;

We'll make a quick macro for the number of fractional bits:


Then we'll define two conversion functions:

/// Converts 11.5 format -> double
double fixed_to_float(fixed_point_t input);

/// Converts double to 11.5 format
fixed_point_t float_to_fixed(double input);

Now that we've gotten the groundwork out of the way, we'll write our fixed-point to floating-point conversion function. Converting from fixed-point to floating-point is straightforward. We take the input value and divide it by (2fractional_bits), putting the result into a double:

inline double fixed_to_float(fixed_point_t input)
    return ((double)input / (double)(1 << FIXED_POINT_FRACTIONAL_BITS));

To convert from floating-point to fixed-point, we follow this algorithm:

  1. Calculate x = floating_input * 2^(fractional_bits)
  2. Round x to the nearest whole number (e.g. round(x))
  3. Store the rounded x in an integer container

Using the algorithm above, we would implement our float-to-fixed conversion as follows:

inline fixed_point_t float_to_fixed(double input)
    return (fixed_point_t)(round(input * (1 << FIXED_POINT_FRACTIONAL_BITS)));

However, not all of our embedded systems utilize the standard library, and perhaps round() is not supplied. You can also just rely on truncation when converting to an integer. There will be some precision loss, but for a quick-and-dirty solution that may be acceptable:

inline fixed_point_t float_to_fixed(double input)
    return (fixed_point_t)(input * (1 << FIXED_POINT_FRACTIONAL_BITS));

If you need to support multiple fixed-point styles, you can provide interfaces for various integer widths and add the fractional bit count as an input argument:

// Convert 16-bit fixed-point to double
double fixed16_to_double(uint16_t input, uint8_t fractional_bits)
    return ((double)input / (double)(1 << fractional_bits));

// Equivalent of our 11.5 conversion function above
double r = fixed16_to_double(input, 5);

There you have it: quick-and-dirty fixed-point conversion methods.

Further Reading

Related Posts