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

[Simon Clubley]

On 2021-09-27, chris <chris-nospam at tridac.net> wrote:
> On 09/27/21 19:49, Simon Clubley wrote:
>>
>> Because the buffer behind the pointer gets directly written to by the
>> operating system outside the normal flow of execution while the program
>> is busy doing something else.
>
> Yes,. it does, but the compiler has no knowledge of that at all, as it's
> a run time thing, not compile time. Unless the compiler has a crystal
> ball :-). Can have no idea of what underlying code might modify the
> buffer.
>

We have been through this several times Chris.

The whole point of volatile is that the compiler doesn't need to know.
When the variable _is_ accessed again in the code, the read is left in
instead of possibly being deleted by the optimiser.

>>
>> At that point, any cached contents of that buffer become invalid
>> and need to be re-read. Volatile guarantees that will happen and _if_
>> the code walks through a sequence point before reading the modified
>> buffer that should cause it to happen as well (ignoring possible
>> optimiser bugs :-)).
>
> No, volatile does no such thing. It's merely a hint to the complier to
> apply no optimisation to it.
>

And how is the hint implemented ? Answer: by not optimising away what
the optimiser would otherwise think may be a redundant read.

So yes, it's exactly how it works.

>>
>> However, volatile, which has no downsides other than a few extra
>> cycles, will _guarantee_ that will happen without you having to worry
>> about if you have gone through a sequence point or if the optimiser
>> has done something unexpected.
>>
>> This is no different from hardware writing directly into your memory
>> space from outside the normal flow of execution of your code.
>
> Quite common in interrupt handlers, but again, the compiler can't
> predict the future as to when it will be modified, or by whom,
> so how can it add code to mitigate what it can't understand ?.
>

The whole point of volatile is that it doesn't need to predict the
future. The variable is always re-read before the contents are used
for something and as I clarified a few messages back, it's not about
adding code, but instead about not removing code the optimiser would
otherwise think is redundant.

>
> That's how this started, right, VMS sys$qio having bugs internally ?.
>

No. The concern was that people might not be correctly marking buffers
and data structures as volatile when using system services in full async
mode and that might catch them with a compiler with a different optimiser
(ie: LLVM).

>>
>> I've just checked some FreeBSD headers available online and it
>> turns out that AIO on FreeBSD also marks the transfer buffer
>> as volatile.
>>
>
> Well, there is a lot of cross fertilisation between the two OS. The
> only reason I can think of for the pointer to be declared with
> a volatile keyword is that if the buffer is declared volatile, then
> the point also needs to be to avoid whinges about incompatible types.
> Can see no reason for it otherwise...
>

It's not a volatile pointer Chris, it's a normal pointer to
a volatile buffer. The only thing that's volatile is the buffer
behind the pointer (which is how it should be). The pointer itself
is not volatile.

Simon.

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