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

[chris]

On 09/23/21 18:51, Simon Clubley wrote:
> On 2021-09-23, chris<chris-nospam at tridac.net>  wrote:
>>
>> So what is the issue here ?. Keywords like volatile would not normally
>> ever be used at app level, being reserved for low level kernel and
>> driver code where it touches real hardware registers. or perhaps
>> memory locations reserved for a specific purpose.
>
> There are a number of instances where it is quite valid (and expected)
> to use a volatile attribute in normal applications, especially when
> asynchronous I/O is involved.
>
> The use of volatile is not restricted to those who know the resistor
> colour code chart off by heart. :-)
>
> For example, Linux uses it (correctly) in its own asynchronous I/O interface:
>
> https://man7.org/linux/man-pages/man7/aio.7.html
>
>>
>> If systems and code are designed and written properly, then it should
>> compile to usable code irrespective of compiler, including
>> optimisation level, so long as the compiler is standards compliant.
>> Anything else is s system design issue...
>>
>
> In this case, the standards compliant approach would have been to require
> the volatile attribute from day 1 on those variables/fields/buffers which
> are filled in _after_ the system call has returned control to the program.
>
> Simon.
>

If you look at that use of volatile, it's dealing with sig_atomic,
which I would guess to be an interface to a test and set instruction,
which is  designed to be indivisible and non interuptable. That is,
the whole instruction always executes to completion.
More like driver level code, not application, where such
functionality would normally be encapsulated into a system call.

The hard barrier between kernel and application code is there
for very good reason :-)...

Chris