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

[Jan-Erik Söderholm]

Den 2021-09-23 kl. 02:07, skrev 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
> 

Sorry. Seems to be something about a "memory barrier". I don't know
what that is in this context and if it works as an volatile.