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

[Simon Clubley]

On 2021-10-02, chris <chris-nospam at tridac.net> wrote:
> On 09/28/21 19:32, Simon Clubley wrote:
>
>>
>> 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.
>
> A buffer would never be deleted by an optimiser, but if you think so,
> please explain.
>

Until now Chris, I wasn't sure if you were trolling or were yet another
hardware type who didn't understand software as well as they liked to
think they did, so I gave you the benefit of the doubt.

Given the blatant way you have now replied to something very different
from what I said and given the way you have ignored elsewhere what
I said, it is now clear you are trolling.

I will however, give you this last response.

You have asked above about buffers being deleted, which is something
that has not been discussed until you raised it just now. That's a
perfect example of why I now think you are trolling as your reply
was about something that was never said.

As you should be aware of, if you understand this as well as you claim,
at generated code level, a read can be either a standalone read or it
can be part of a read/modify/write sequence.

In either case, all the optimiser does is decide if it can delete the
read part of that because it thinks it has the value already cached
and hence a memory read is not required.

>> 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.
>>
>
> So tell me, what exactly "rereads" the variable, code added by the
> compiler, or what ?
>

The read as part of the read/modify/write sequence or the standalone
read which in either case was not deleted by the optimiser because the
optimiser was told not to delete it.

>> 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).
>>
>
> Perhaps, but you can give no good reason why that might be the case,
> or technical argument to support such a theory.
>

Well, actually I did a bit of digging and it turns out the VMS programming
concepts manual, even as far back as VMS 7.3-1, recommends the volatile
attribute in some circumstances when calling some system services.

Here's an example in Pascal:

http://odl.sysworks.biz/disk$axpdocdec021/opsys/vmsos731/vmsos731/5841/5841pro_055.html

What I am worried about is just an extension of that.

>>>>
>>>> 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.
>
> No, but the point I was making that the pointer is declared volatile
> to avoid complier whinges about incompatible  types, if you
> had read what I said. If something is declared volatile, then the
> compiler will take note, whether it needs to or not, but will have
> no effect on the resulting code.
>

The pointer itself isn't volatile. It's the buffer behind that pointer
which is volatile. In C, those are two different things. Here's some
material I've just found which explains the difference:

https://stackoverflow.com/questions/9935190/why-is-a-point-to-volatile-pointer-like-volatile-int-p-useful

> See a lot of use of volatile where it's not needed, because so many
> do not understand it's use. Does no harm, but shows lack of
> understanding...
>
> Chris

Or it could be considered an example of robust programming so that
someone doesn't have to worry that they have got the need for it
wrong. It's no different from doing boundary checks in your code
manually at runtime in languages that don't do automatic boundary
checks even though you are "sure" :-) that you wrote the code
correctly to begin with.

Simon.

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