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

[Dave Froble]

On 10/2/2021 12:37 PM, Simon Clubley wrote:
> 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.
>

Ok, poll time.  Is there anyone else that took as long as Simon to 
realize he was being trolled?

:-)

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486