Return to Answer

• representing hardware registers (or memory-mapped I/O) as variables - even if the register will never be read, the compiler must not just skip the write operation thinking "Stupid programmer. Tries to store a value in a variable which he/she will never ever read back. He/she won't even notice if we omit the write." Conversly, even if the program never writes a value to the variable, its value may still be changed by hardware.
• sharing variables between execution contexts (e.g. ISRs/main program) (see @kkramo's answer)

• representing hardware registers (or memory-mapped I/O) as variables - even if the register will never be read, the compiler must not just skip the write operation thinking "Stupid programmer. Tries to store a value in a variable which he/she will never ever read back. He/she won't even notice if we omit the write." Conversly, even if the program never writes a value to the variable, its value may still be changed by hardware.
• sharing variables between execution contexts (e.g. ISRs/main program) (see kkramo's answer)

• representing hardware registers (or memory-mapped I/O) as variables - even if the register will never be read, the compiler must not just skip the write operation thinking "Stupid programmer. Tries to store a value in a variable which he/she will never ever read back. He/she won't even notice if we omit the write." On the other hand, even if the program never writes a value to the variable, its value may still be changed by hardware.
• sharing variables between execution contexts (e.g. ISRs/main program) (see @kkramo's answer)

If result was volatile (and not local), every occurrence of result in the C code would require the compiler to perform an access to RAM (or an I/O port), leading to a lower performance.

• representing hardware registers (or memory-mapped I/O) as variables - even if the register will never be read, the compiler must not just skip the write operation thinking "Stupid programmer. Tries to store a value in a variable which he/she will never ever read back. He/she won't even notice if we omit the write." Conversly, even if the program never writes a value to the variable, its value may still be changed by hardware.
• sharing variables between execution contexts (e.g. ISRs/main program) (see @kkramo's answer)

If result was volatile, every occurrence of result in the C code would require the compiler to perform an access to RAM (or an I/O port), leading to a lower performance.

The other classic example is like this:

Secondly, the compiler may re-order operations on non-volatile variables for performance and/or code size. Simple example:

int a = 99;
int b = 1;
int c = 99;

could be re-ordered to

int a = 99;
int c = 99;
int b = 1;

which may save an assembler instruction because the value 99 won't have to be loaded twice.

If a, b and c were volatile the compiler would have to emit instructions which assign the values in the exact order as they are given in the program.

The other classic example is like this: