Hello..


I was just reading this interesting webpage about:
"Everything that’s Wrong with the C++ and Object Pascal Languages":

https://blog.digitaltundra.com/?p=403

And as you have noticed that it says about Delphi the following:

"A [volatile] attribute was quietly slipped into the newest versions of
delphi, but AFAIK it likely only affects the iOS/Android compilers, and
its effects are not really well documented… see this white paper for more)."

and it says also the following:

"Again, this isn’t a problem in Delphi only because non-local memory is always considered volatile"


So from the above you are understanding that Delphi is keeping
compatibility on windows with older windows Delphi compilers that don't
support volatile.

And Freepascal is the same since i wrote the following to make you
understand it:


I have just read the following about Freepascal:

----

The old volatile discussions with Thaddy...

In my understanding:

Volatile guarantees that the variable accesses in statements are not
optimized to registers etc. In fpc there was no such concept (I heard it
was introduced lately), so all non local variables have to be dealt as volatile, especially in multithreading applications. A prominent example
where "volatility" is needed is the TThreat.Terminated property
(boolean). A strong optimization of the loop
while not terminated do
should recognize that it isn't modified within the loop, so for a
non-volatile "terminated" it could be optimized to
if not terminated do
Of course this would break the code. In case of fpc the volatility is
implizit, as said, all non local variables are volatile. But this
prevents such optimizations for all variables, also those, that don't
need volatile behaviour.

I see a problem in the introduction of a volatile keyword, the backward compatibility. The keyword only makes sense, if optimizations are
implemented, that recognize the keyword. If this is the case than old
code with the missing keyword gets broken.

This means in fpc you can just leave the [volatile] away.

Read more here:

https://forum.lazarus.freepascal.org/index.php?topic=46083.0

---


So i have also written the following:

I have just read the following about volatile from Barry Kelly:

"Specifically, volatile prevents the compiler from changing the number
of reads or writes to or from a location from the number that are
explicitly indicated in the source. That doesn't mean that the reads or
writes to volatile locations will act as memory barriers.

To my knowledge, current implementations of Win32 Delphi never change
the number or order of reads or writes to global variables or fields of objects."

Read more here:

http://borland.newsgroups.archived.at/public.delphi.language.delphi.win32/200606/0606232337.html

So i think the old Delphi compilers that don't support volatile never
change the number or order of reads or writes to global variables or
fields of objects, and i think since Freepascal in the Delphi mode is compatible with the old Delphi compilers that don't support volatile, so
then Freepascal in the Delphi mode never change the number or order of