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

[Arne Vajhøj]

On 9/23/2021 8:24 AM, Simon Clubley wrote:
> On 2021-09-22, Jan-Erik Söderholm <jan-erik.soderholm at telia.com> wrote:
>> Den 2021-09-23 kl. 02:07, skrev Arne Vajhøj:
>>> But instead of spreading out volatile keyword wouldn't
>>> __MB() do the same? (on VMS - it is a VMS C specific thing
>>> I believe)
>>
>> Sorry. Seems to be something about a "memory barrier". I don't know
>> what that is in this context and if it works as an volatile.
> 
> Assuming __MB() is a hardware memory barrier operation, the answer is no.
> 
> Memory barrier instructions are designed to get bits of hardware back
> into sync with each other so that when you read something it is valid.
> 
> Volatile OTOH is a purely software construct and is used to tell the
> compiler to insert bits of code into the generated code to _always_
> first re-read the memory location even if the compiler thinks from
> looking at the source code that the value could not have changed.
> 
> There's no point getting the hardware back into sync, if the generated
> code is missing the bit to then unconditionally read that value again
> before doing something with the variable.
> 
> Even if memory barriers could be made to so the same thing somehow
> by having the compiler look for them, they would have to be inserted
> within the executable code. Volatile however is a variable definition
> attribute so only ever appears in the source code when the volatile
> variables are initially defined.

__MB should ensure that when the code reads from memory
it should get the latest value.

A buffer with 100 or 1000 or 10000 bytes can not be in
a register (at least not on x86-64) so reading the buffer
will mean reading from memory.

And if __MB ensure that reading from memory will get the
latest value then ...

Arne