[Info-vax] LLVM, volatile and async VMS I/O and system calls

[chris]

On 10/03/21 19:53, Jan-Erik Söderholm wrote:

>
> Well, the whole point of this discussion is that the second
> copy is *NOT* redundant. Adding "volatile" makes that clear.
>

Well, it's not a particularly good example in terms of typical
use of volatile, though it does show complier action.

> The value of a *could* have changed between the two reads.
> That is exactly what "volatile" is all about.
>

Err, yes.

>>
>> One of the points I was trying make earlier was that code
>> should never depend on optimisation level,...
>
> If you add "volatile" where it is needed, you do not need to
> depend on any optimisation level. And one "volitile" too
> much is usually better then one to little.
>

Using something where it's not needed suggests lack of
understanding, but ymmv. Use volatile keyword all the time
in embedded work. It's well understood and proven, but
never in upper layer app code. Wrong context, though on
some older systems, there might have been little
demarcation between system and application levels. A typical
modern OS provides so much in terms of system services, one
might never need to be even aware of things like volatile,
unless you were writing driver or specialised library
level code.

>> and for app
>> code, there are better high level methods for
>> controlling shared access, such as signals or callbacks
>> to encapsulate an async process.
>
> If a had been pointing to some hardware register, that is
> updated by the hardware and not by other code, no signals,
> callbacks or any other coding technique can change that.
> *The* way (in C) is to add "volatile" to the varaible.
>
> It has nothing to do with coding style or such, only with
> proper understanding of the context the code is running in.
>

No one was talking about coding style, just that other higher
level techniques are typically used at app level to ensure
security around shared access. If you think that's incorrect,
please explain. I think someone mentioned EV6 causing problems
but wasn't that the first Alpha to run out of order
execution ?. That might upset quite  few things if the code
assumed in order execution as written. Order of execution can
matter a lot in some areas...

Chris



>>
>> Good tech discussion this though :-)...
>>
>> Chris
>>
>>
>>
>>
>>>
>>> Most interesting.
>>>
>>> bill
>>
>