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

[chris]

On 09/24/21 19:15, Simon Clubley wrote:
> On 2021-09-24, chris<chris-nospam at tridac.net>  wrote:
>
> Chris, you are even more stubborn than Arne. :-) (Sorry Arne :-))
>
>> On 09/24/21 13:09, Simon Clubley wrote:
>>> On 2021-09-23, chris<chris-nospam at tridac.net>   wrote:
>>>>
>>>> Still doesn't explain why a volatiie keyword might be needed at
>>>> application level, though I guess there might be a few edge cases...
>>>>
>>>
>>> I'm surprised you are having a hard time seeing it Chris.
>>>
>>> Hardware stuffs something directly into process memory outside of
>>> the flow of execution of a program, hence volatile may be required
>>> for some programs to tell the compiler to generate code to re-read
>>> it again.
>>>
>>
>> Sorry, but that's incorrect. You are confusing compile time actions
>> with runtime  situations. Present C compilers can have no
>> knowledge of future dynamic runtime situations where, for example, a
>> shared buffer may be updated asynchronously by separate processes
>> and at different times. However, most operating systems have features
>> to manage such situations to ensure things like mutual exclusion and
>> deadlock  prevention. Os books are full of algorithms for that sort
>> of thing, as it's so fundamental to OS design.
>>
>
> No I am not. All I have said all along is that volatile inserts code
> into the generated code to _always_ re-read the variable before doing
> anything with it.

Sorry, no it doesn't :-). All it's saying is that the section of code 
should not be subject to any optimisations. Not the same thing at all.
Doesn't add code, just doesn't take any away, nor modify it,
but translates as written.

Of course in the real world, out of order execution on modern micros
can be a can of worms in itself, if the code depends on a specific
sequence of instruction execution, which of course, it never should.

Chris