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

Jan-Erik Söderholm jan-erik.soderholm at telia.com
Wed Sep 22 19:53:38 EDT 2021


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?
> 
> Arne
> 

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.

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.

AST, does in a way look like this, some data (the buffer) in the app
is changed without this beeing obvious from just looking at the code.
That is, as the compiler is doing. That is what Simon is asking about.

I am very well aware of these issues with microcontrollers from a long
time programming "8-bitters" in the Microchip PIC family. I have no
idea how this relates to ASTs...


Jan-Erik.








More information about the Info-vax mailing list