[Info-vax] Volatile, was: Re: yet another sys$qiow question

[Simon Clubley]

On 2015-08-19, Bob Gezelter <gezelter at rlgsc.com> wrote:
> On Tuesday, August 18, 2015 at 10:46:50 PM UTC-4, John Reagan wrote:
>> On Tuesday, August 18, 2015 at 7:45:35 PM UTC-4, George Cornelius wrote:
>> > 
>> > The whole volatile thing appears to have been a distraction.  As far as
>> > I can tell, the C compiler never issues memory barrier instructions when
>> > referencing volatile data, and, as John has pointed out, volatile is
>> > not really needed as a hint to the compiler that the data might change
>> > asynchronously as long as it already knows that the address of the
>> > entity has been taken and passed to external code, because it
>> > apparently has an internal implementation of a 'weakly volatile'
>> > designation.  But if you do not synchronize, and it does change
>> > between two successive calls to external code, the compiler is
>> > free to remember, say, the value it read the first time in a
>> > sequence of uninterrupted local code and not fetch it separately
>> > each time thereafter.
>> 
>> You don't need memory barriers.  You do need volatile.  The IOSB is
>> written behind your back.  volatile says we have to re-fetch.
>> 
>> I think you misunderstood my prior posts.  Places that only need a
>> 'weak volatile' are places where you took the address of something
>> (for example, put the address of a variable into an item list
>> descriptor) and then call some system service that would write that
>> variable for you.  But C doesn't have a weak volatile.  You can get
>> away without using volatile, but in general, I'd recommend it at least
>> for documentation purposes.
>> 
>
> John,
>
> Going back to Code Generation 101, I would think that a "volatile"
> would only be relevant within a basic block. As I recall, the
> definition of a basic block is "one entrance, one exit". Thus, an
> out-of-line subroutine call ends a basic block by definition.
>

But the IOSB can be written by VMS if the I/O (started from elsewhere
within the program) completes _while_ the basic block is executing.

> I do not have my Alpha or IA64 architecture specification handy, but
> what is the official definition concerning memory barriers and
> subroutine calls/branches?
>

If I understand John correctly, that's not really the issue here.
The issue is that the VMS design can change the contents of user
space process specific memory (the address space allocated to the
IOSB) behind the program's back without the program having to make
an explicit call to update that memory.

This is the classic case for the use of volatile in embedded systems.

It also raises another very interesting issue. From what John appears
to be saying, it sounds like the DEC compilers were written with this
situation in mind.

However, in this type of situation gcc can be really aggressive here
about moving code around unless volatile is in use (this comes up on
comp.arch.embedded on a regular basis). I don't use LLVM, but I wonder
if code which works with DEC C will continue to work reliably with
LLVM if LLVM is as aggressive as gcc at moving things around.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world