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

[chris]

On 10/02/21 17:37, Simon Clubley wrote:

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

You are obviously missing the irony, since your original post at
thread start looked like trolling, casting aspersions as it did, as
though the vms team would miss something like that ?.

To Quote:

> With the move to LLVM, and its different optimiser, have any examples
> appeared in VMS code for x86-64 where volatile attributes are now required
> on variable definitions where you would have got away with not using them
> before (even if technically, they should have been marked as volatile anyway)

VMS has been rewritten twice already and i'm sure they must have run
into such issues in the past.

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

Either register, as you suggest, or go back out to memory. Helps to be
specific about what you mean.

>
>>> 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, it really comes down to optimiser choice of instruction, depending
on the use of the volatile keyword. Perhaps optimisers might optimise
such reads out, but that common ?.

>
>>> 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 would assume that the vms folks know what they are doing, respect
for the assumed knowledge and past attention to detail etc.

>>> 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, the pointer has been declared volatile, for the reason I gave 
earlier, that it points to a volatile declared object.

> 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

A good example.

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

At least the discussion stays civil in this group and the result
is often that we check our assumptions and learn something new :-)...

Chris