[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