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

[Simon Clubley]

On 2021-09-24, Arne Vajhøj <arne at vajhoej.dk> wrote:
> 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.
>

__MB() puts the hardware holding the contents of that variable into sync.
Volatile OTOH puts the generated code for that variable into sync by not
caching the variable but instead re-reading it every time.

IOW this only works if the code _does_ read from memory every time
at which point you don't need the memory barrier anyway, at least not
for this. You may still need a memory barrier down inside the device
drivers or in the kernel, but that's nothing to do with working around
the compiler generating code to cache the variable instead of re-reading
it every time.

If you could somehow get this to work, you would also have to manually
insert the __MB() instructions throughout your code instead of just
tagging the variable as volatile and letting the compiler add code
to do a re-read automatically.

> 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.
>

That's non-deterministic. What if the code only looks at the first
longword in the buffer ? A longword that it looked at previously
when the buffer had previous contents ? Oops... :-)

A __MB() call here would make no difference to that behaviour.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.