[Info-vax] yet another sys$qiow question

[David Froble]

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.
> 

Ok, just so dumb me can understand, did you just write that before I'm notified 
of the completion of a QIO, the IOSB has been updated and ready to read?  I 
really cannot imagine anything else.  I do understand that prior to that 
notification that the contents of the IOSB is indeterminate, or worse.

I also have a poor opinion of some optimizer bypassing code that I've written. 
If I wrote it, I want it to execute, regardless of what some optimizer thinks.