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

[Simon Clubley]

On 2021-09-22, Bob Gezelter <gezelter at rlgsc.com> wrote:
> Simon,
>
> Since the days of RSX-11M, I have been dealing with client bugs in this area.. The best phrasing I have seen in this area was in an IBM System/360 Principles of Operation manual. It may have only appeared in certain editions, as I cannot find the precise reference. However, it was along the lines of "the contents of a buffer are UNDEFINED [emphasis mine] from the initiation of the I/O operation until the operation has completed with the device end signal from the device."
>
> In OpenVMS speak, the above translates as: "The contents of the buffer are undefined from the issuance of the QIO system call until such time as the I/O is completed, signaled by the queueing of an AST; setting of an event flag; or the setting of the completion code in the IOSB."
>

That isn't the concern Bob.

The concern is, given the highly asynchronous nature of VMS I/O and
of some VMS system calls in general, and given the more aggressive
LLVM optimiser, does the generated code always correctly re-read the
current contents of buffers and variables without having to mark those
buffers/variables as volatile ?

Or are there enough sequence points in VMS application code where these
buffers and variables are accessed that this may turn out not to be a
problem in most cases ?

In essence, the VMS system call and I/O system is behaving much more
like the kinds of things you see in embedded bare-metal programming
than in the normal synchronous model you see in the Unix world.

There's a reason why volatile is used so liberally in embedded bare-metal
programming. :-)

Simon.

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