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

[Arne Vajhøj]

On 9/22/2021 7:53 PM, Jan-Erik Söderholm wrote:
> Den 2021-09-23 kl. 01:22, skrev Arne Vajhøj:
>> On 9/22/2021 4:25 PM, Simon Clubley wrote:
>>> On 2021-09-22, Bob Gezelter <gezelter at rlgsc.com> wrote:
>>>> 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.
>>>
>>> But VMS writes directly into your process space at some random time
>>> X later _after_ you have returned from sys$qio() and are potentially
>>> busy doing something else.
>>>
>>>  From the viewpoint of the application, it's exactly the same as 
>>> hardware
>>> choosing to write an updated value into a register while your bare-metal
>>> code is busy doing something else.
>>>
>>> How does the compiler know VMS has done that or are there enough
>>> sequence points even in the VMS asynchronous I/O model for this
>>> to still work fine without having to use the volatile attribute,
>>> even in the presence of an highly aggressive optimising compiler ?
>>
>> This is a bit outside my area of expertise.
>>
>> But wouldn't a flow like:
>> - call SYS$QIO with buffer
>> - do something
>> - wait for IO to complete
>> - __MB()
>> - use buffer
>> work?
> 
> One important point is of course to not use the buffer until the
> QIO related to that buffer completes. But that is not really what
> Simon is talkning/asking about.

That is a given. And why I had the "wait for IO to complete".

> Simon is refering to the well known issue on platforms where a
> variable can directly refer to some data that might get updated
> outside of the controle of the application code (and then also
> not being able to be analysed by a compiler optimizer.
> 
> One very common case is where a variable refers to an "port"
> on a microcontroller. The port is connected to some real life
> equipment such as push buttons, relays or what ever. Those items
> can be handled totaly out of control from the application code.
> 
> In those cases, it is very common that the compiler says "this
> variable has not been updated, so I'll just use the value from
> the last read that I already have in a register anyway". And
> then missing some push button being pressed.
> 
> That is where you say "volatile" to disable any such optimization and
> force the compiler to always re-read the variable from the source.

Yes.

But instead of spreading out volatile keyword wouldn't
__MB() do the same? (on VMS - it is a VMS C specific thing
I believe)

Arne