[Info-vax] yet another sys$qiow question

[Simon Clubley]

On 2015-08-19, Bob Gezelter <gezelter at rlgsc.com> wrote:
> For those without an Alpha Architecture manual at hand:
>
> 5.6.3  Implied Barriers
> There are no implied barriers in Alpha. If an implied barrier is needed for functionally correct access to shared data, it must be written as an explicit instruction. (Software must explicitly include any needed MB, WMB, or CALL_PAL IMB instructions.) Alpha transitions such as the following have no built-in implied memory barriers:
> * Entry to PALcode
> * Sending and receiving interrupts
> * Returning from exceptions, interrupts, or machine checks
> * Swapping context
> * Invalidating the Translation Buffer (TB)
>
> - Bob Gezelter, http://www.rlgsc.com

Hello Bob,

I see John's made the same comment about the IOSB while I was writing
my response as I did.

What you say above is correct but for the benefit of others following
along, I just want to clarify that barriers are _nothing_ to do with
the IOSB situation; barriers are _very_ localised sequences designed
to ensure correct ordering of data at that specific point in time.

The IOSB situation, where process memory can be changed by the operating
system at some random point in the future without an explicit call by
the process to the operating system, is an artifact of the VMS design
and is an artifact which appears to be handled correctly by the current
DEC compilers.

Next question: do process space I/O buffers have to be marked as volatile
as well for the same reason ?

>From the compiler's viewpoint, it's the same situation as the IOSB;
a chunk of memory (the I/O buffer) can be written to by VMS at some random
point in the future without any explicit action by the process to update
that buffer.

Simon.

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