Force read of volatile variable

Question

An embedded project I'm working on requires reading a specific location in memory, but the value of that memory location is not needed. Currently I am reading the volatile variable into a dummy variable as in foo1() below, but I am curious about the method in foo2().

void foo1(void) {
    volatile uint32_t *a = (volatile uint32_t *)0xdeadbeef;
    volatile uint32_t discard = *a;
}
void foo2(void) {
    volatile uint32_t *a = (volatile uint32_t *)0xdeadbeef;
    *a;
}

See the dissassembly (compiled with gcc 4.7.2 and -O3):

  foo1:
movl      0xdeadbeef, %eax
movl      %eax, -0x4(%rsp)
ret
  foo2:
movl      0xdeadbeef, %eax
ret

The method in foo2() seems to work, but I want to know if it is guaranteed to work and isn't a side effect of the compiler version and optimizations I am using.

Answer 1

It's standard in C, but not C++. See: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Volatiles.html

BUT, you certainly don't need to do the volatile write to discard. These will probably all compile to the same as foo2:

• use foo1, but remove the volatile qualifier from discard; or
• use foo2, but use !*a or *a + 0 instead of *a. The value must be accessed in order to evaluate the expression, even in C++

Answer 2

The keyword volatile tells the compiler an object might change outside the scope of the normal (i.e. visible by the compiler) program flow. Therefore, the compiler performs this access in general. The last sentence refers to how the access is performed, e.g. byte-read, unaligned reads, etc.

Futhermore, the compiler must execute all accesses to such objects in the order given by the program flow. Note, however, that it may reorder accesses to non-volatile objects freely and the underlying hardware might think different, too (the compiler might not know that).

The compiler might still optimize accesses to volatile objects which exist and are modified only in the visible code. This is true for local variables where the address is not taken (there might be other situations), as these cannot be reached outside the scope. For the pointers you use, this is not true, as the compiler does not know about the object they point to.

To drop the result of an expression without compiler warning, just cast it to void:

volatile uint32_t *vi = ...;
(void)*vi;            // this still might be optimized if vi is local

(If the target is read-only, add const.)

See the gcc documentation for details on volatile accesses. An implementation which complies to the C standard has to provide this information.

Also note that the underlying hardware still might reorder the accesses, unless the memory area uses a strictly ordered/non-cached access policy. This is typical for memory-mapped peripheral registers. If a cache/MMU is used, the areas might have to be set up accordingly.

Answer 3

There is no guarantee that dereferencing a volatile object causes a read access, see ISO 9899:2011 §6.7.3 ¶7:

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. ¹³⁴⁾ What constitutes an access to an object that has volatile-qualified type is implementation-defined.

¹³⁴⁾ A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be “optimized out” by an implementation or reordered except as permitted by the rules for evaluating expressions.

In practice, implementations of the C programming language commonly define unary * to constitute an access to an object, thus guaranteeing that *a is causing a read access to a volatile variable a.