What is extern volatile pointer

Question

What is extern volatile pointer.

extern volatile uint32 *ptr;

Here, what will be the behavior of *ptr? What does this actually mean?

<

Answer 1

I would explain the way I know through the keywords. extern means the variable is defined for use somewhere outside the definition scope. For example it could be defined in header file and get used in .c file.

volatile means that modification of that variable should be consistent to the external world. This means that all update should be committed to the main memory so that it can be seen by other threads which share the same execution space.

Answer 2

extern keyword is used to declare a global variable which is defined somewhere else (that means its defined in some other .c file).

For example consider in a project two .c files a.c and b.c are there. In that a global variable is defined in a.c, and that variable can be accessed in all the functions which are defined in that file. If we want to access that same global variable in our second file b.c, then that variable should be declared as extern in b.c

a.c file is given below

int flag = 0;
int main()
{
    .......
    func1();
    printf("\nflag value is %d\n", flag).
    ....... 
}

b.c file is given below

extern int flag;
void func1();
{
    .....
    flag = 10;
    .....
}

volatile keyword is used to inform the compiler to avoid doing any sort of optimization while generating executable instructions.

int flag = 0;
int main()
{
    while(flag == 0);
    printf("\nflag value is %d\n", flag);
    return 0;

}

Consider the above program, all compiler will optimize the while(flag == 0); as while(1);. Because in the code there is no where flag value gets updated before that while loop. So if that variable value gets updated by some other hardware then it will never get reflected in the program execution. So if we declare that variable as volatile like below, compiler will not perform any optimization for that variable, and the behviour of that program will be as intended.

volatile int flag = 0;

But if there is no way for the value of program's variable is getting updated by other hardware, then no need to declare that variable as volatile. Because for valatile variables, CPU needs to perform I/O operation for each instructions which is accessing that variable. This impact in performance needs to be consider for a variable which will never get updated by other hardwares.

Answer 3

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.

Answer 4

Extern means it is defined elsewhere - probably in the header file. Volatile is info for the compiler that it shouldn't try to optimize this.