Both extern and volatile keywords can be considered independently. The role of each of these keywords does not interact with the other one, and thus an explanation of each of them can be detailed independently, as below.
extern tells the compiler that the actual definition of ptr is in another module (another .c
). Basically, there is no much change to how the compiler handles ptr - having extern just tells the compiler that it does not have to reserve some space in memory for ptr as it is done elsewhere in another .c
, and its actual memory location will be given by the linker later.
extern uint32 *ptr;
If you omit extern the compiler will not complain. However, later, the linker, when it tries to link all object modules in order to build the final executable program, will throw an error saying "ptr is defined twice" (since it is already defined in another .c
).
uint32 *ptr;
volatile tells the compiler that the memory location where ptr resides may be altered / modified by some external event, and it (the compiler) should not rely on some efficiency optimizations like considering that the value of ptr will not change during the scope of a few sequential lines of C. Such an event may be an asynchronous interruption, that happens when the CPU executes the above said scope, and modifies the ptr value.
Typically (with virtual assembly code of optimized C in comments), REGx are CPU registers, and we are not much interested in the variable y...
int x = 10;
int func() {
int y; // REG4
printf("%d\n", x); // Set REG3 = memory(x) and display x
x += 2; // Add 2 to REG3
y = x * x; // REG4 = REG3 * REG3
printf("%d %d\n", x, y); // Do printf(..., REG3, REG4)
x += 5; // REG3 = REG3 + 5
// memory(x) = REG3 (save register to memory)
return y; // return REG4
}
should display 10, 12, 144
. For the sake of efficiency (memory accesses are more costly than register accesses) say the compiler stores the value of x in an internal CPU register (REG3) and uses it in func safely until the end where it stores the new value of x (it's a global var) to x memory location. x is 17 at the end.
But imagine the program is more complex than that and has a clock interruption every minute that subtract 10 to x. What happens if an interruption...
void inter_call_by_timer_every_minute() {
x -= 10;
}
... occurs in func say just after the printf("%d\n", x);
line? func has x in REG3 (10), add 2 (12) and finally add 5 (17) and stores the REG3 result to x memory location (17). This is wrong as the interruption effect (-10) has been hidden by the compiler optimization, since it stores the value from REG3 to memory(x) at the end ignoring the subtract done by the interruption. The correct result was: x is initially 10, interrupt subtract 10 to it (0) after the first printf
in func, then 2 is added, then 5. Result 7.
Adding volatile
volatile int x = 10;
will have the compiler avoid the x optimizations in func
int func() {
int y; // REG4
printf("%d\n", x); // display memory(x)
x += 2; // memory(x) += 2
y = x * x; // REG4 = memory(x) * memory(x)
printf("%d %d\n", x, y); // Do printf(..., memory(x), REG4)
x += 5; // memory(x) += 5
return y; // return REG4
}
and read the value of x from memory all the time. Result, having an interruption from inter_call_by_timer_every_minute after the first printf, is x == 7.