[fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?
Marco van de Voort
marcov at stack.nl
Fri Dec 18 11:29:54 CET 2015
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".
More information about the fpc-pascal