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

[Bob Gezelter]

On Wednesday, September 22, 2021 at 2:11:40 PM UTC-4, Simon Clubley wrote:
> On 2021-09-22, Bob Gezelter <geze... 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.
Simon,

Good technical question.

In general, optimizers work within basic blocks. The example of concern is not a single basic block.

A basic block is a section of code with one entry and one exit. Simple IF statements fall within that category. However, any out-of-line code invocation does not. 

The presence of the SYS$QIO system service, which one way or another involves a CALL, ends the basic block, as the optimizer cannot know what is modified by the out-of-line call or its descendants.

- Bob Gezelter, http://www.rlgsc.com