[Info-vax] yet another sys$qiow question

[Bob Gezelter]

On Wednesday, August 19, 2015 at 8:00:00 AM UTC-4, John Reagan wrote:
> On Wednesday, August 19, 2015 at 7:11:42 AM UTC-4, Bob Gezelter 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.
> > > 
> > > You only need memory barriers when you need to define an order of reads & writes to DIFFERENT memory locations.  For example, if you have a buffer and a 'buffer-ready' flag, you want a memory barrier between the writes to the buffer and the write to the ready flag to make sure the buffer is indeed written before you set the flag.
> > 
> > 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. 
> > 
> > I do not have my Alpha or IA64 architecture specification handy, but what is the official definition concerning memory barriers and subroutine calls/branches?
> > 
> 
> Memory barriers and calls have nothing in common.  Reading the Alpha SRM (section 5.6.3, Implied Barriers) goes out of its way to say "There are no implied barriers in Alpha. If an implied barrier for functionally correct access to shared data, it must be written as an explicit instruction."  It then goes on to list things that have no built-in memory barrier just to pound the point home (entry to PALcode, sending and receiving interrupts, returning from exceptions/interrupts/machine-checks, swapping context, invalidating the translation buffer).  None of those impact any pending reads/writes.
> 
> As for volatile IOSBs, consider that you have an IOSB, you pass it to $QIO, and keep processing.  Somewhere in the future that I/O will complete, some system level AST will write into that IOSB.  So from your program's point of view, that IOSB gets a new value "between instructions".  You might even be looping on that IOSB waiting for it to turn from 0 to non-0.  You'll need volatile for that.

John,

Then I am (reluctantly) forced to agree with Hoff. There is a large collection of code with latent problems in the examples.

- Bob Gezelter, http://www.rlgsc.com