[fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

[Marco van de Voort]

In our previous episode, Jonas Maebe said:
> The reason the need for volatile on embedded systems is far less in FPC, 
> is the existence of the "absolute" keyword. In C, you have to declare 
> all of those memory mapped registers as volatile pointers, because 
> otherwise things will get optimised wrongly. In FPC, you can declare 
> them as variables that are "absolute" at some address, and the compiler 
> will never optimise their accesses. Only if you would take the address 
> of one of these variables and store it in a pointer, you would need 
> "volatile" in this context.

(you also need it for variables you access from interrupt routines, as they
might change while a procedure is running)
 
> In FPC, every statement is basically considered to be a compiler-level 
> memory barrier for accesses to global variables. So within a single 
> statement multiple accesses can be optimised, but that cannot happen not 
> across statements. It's not perfect since it inhibits some optimisation, 
> but on the flip side it's very simple and easy to reason about.

That's what I remember from earlier "volatile" discussions. But what about
LLVM?  If you want to squeeze performance out of it, won't that need
volatile sooner or later?

But I agree that this is the usual smart shopping mentality. When shopping
for a compiler, people drone on the most detail optimization opportunities,
but once in production they put it on the lowest common denomitor they
developed/tested with, and call that "validated".