[fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?
Jonas Maebe
jonas.maebe at elis.ugent.be
Fri Dec 18 11:40:10 CET 2015
marcov wrote on Fri, 18 Dec 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
[snip]
>
> (you also need it for variables you access from interrupt routines, as they
> might change while a procedure is running)
If they're global variables, which they presumably are, that's no more
necessary than in the multi-threading case.
>> 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?
It will help, but optimising accesses to global variables is not the
only thing LLVM can do :) Right now, I'll indeed should mark all loads
from and stores to global variables as volatile (which I don't do yet
and therefore tests/test/tmt1.pp gets into an endless loop right now
when compiled with LLVM).
Jonas
More information about the fpc-pascal
mailing list