Am 28.10.2018 um 13:00 schrieb Simon Kissel:
Additionally, in the current FPC code generator global variables behave
mostly as volatile variables. With LLVM, that won't be the case (unless
we mark all of their accesses as volatile, but that would obviously
inhibit LLVM optimizations). This may break some multithreaded code that
currently works, and would probably require the introduction of a
volatile() operatator (similar to the unaligned() one). On the other
hand, I already added support for tracking the volatile state of
references in the past, so that should be easy to do.
I have to admit my knowledge on this is very limited. We do
use global variables unsynchronized in Multi-Threaded code,
but only in a single-writer multiple-reader scenarios, in these
cases we don't have any expectations for the new value to be
available "immediately". Obviously the compiler can not know at
what point during runtime the thread gets scheduled, but what
are the rules (if any) on "how long" it takes for a volatile
variables content to get "flushed"? Is there some scoping involved
like "on return of current function/method"?
What volatile means in this context is that the compiler always fetches
the global value anew when it is accessed instead of e.g. caching it in
a register which could be done if global variables would not be
considered as volatile.
Unlike the crap that Embarcadero has been polluting the language
with in recent years, I think that adding support for volatile()
to the language would make a lot of sense - however potentially
turning this around so that the unmodified default stays
volatile, and an implementing an erm.. "non-volatile" modifier
instead, so not to break existing code.
It seems that Delphi changed the default behavior in their NextGen
compiler (probably due to the same reasons that Jonas stated for LLVM)
as they introduced a "[volatile]" compiler attribute to decorate global
variables and fields so that the compiler handles them as volatile...
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
