The documentation states:
Contrary to ordinary constants, a value can be assigned to them at run-time.
In case the compiler optimized things away between different calls then it is the compiler/optimizer at fault, not respecting the consequences of the statement made in the documentation.
For optimisation there is only trouble in case of multithreading, because the constant could be changed in any moment of time and the other thread could be at any place in the code. But exactly the same holds for ALL* variables. (*Only procedure local variables surely cannot be changed from outside).
And I start to believe that this is actually the current situation, i.e. that all variables that are used in more than one procedure (or are published to other units) are treated as volatiles, at least something alike.
E.g. the "Terminated" variable of TThread is normally polled in a loop in the Execute method:
while not Terminated do
Also in most cases the code within the loop doesn't modify the variable "Terminated", but by an other thread to indicate that the thread should terminate itself.
For a compiler seeing "Terminated" as NON-volatile this would mean, its either an infinite loop, or the loop isn't even entered once. Obviously, such optimisation isn't done.
Looking at optimisations, I would expect that the following lines
AComponent.value:= 12;
[...]
AComponent.value:= AComponent.value * a;
are optimized to something like
AComponent.value:= 12 * a;
On the other hand if the variable is used e.g. as locking mechanism:
AComponent. Lockstate:= 2;
[...]
AComponent. Lockstate:= 3;
they may not be optimized, otherwise it breaks functionality.
So my question from the initial post still is open: Are these kinds of variables are treated like volatiles and if yes in what extend.
If the answer is yes, then introducing a volatile modifier actually would mean to introduce non-volatile variables and with that allow deeper optimisations. That may break existing code, though.
If the answer is no, then some improvements are neccessary to make fpc usable on target embedded.
In that regards i also don't fully understand why there would be need for a compiler hint to force this or that, unless it isn't possible to guarantee the compiler behaviour in any other way.
If all variables are volatile by default then of course the compiler behaviour is guaranteed and no optimisation issues can arise (because there couldn't be any variable optimisation be done).
EDIT:
From the programmers guide:
11.1.13 Register variables
When using the
-Or
switch, local variables or parameters which are used very often will be moved
to registers for faster access.
ftp://ftp.freepascal.org/pub/fpc/docs-pdf/prog.pdf#subsection.11.1.13