[Info-vax] yet another sys$qiow question

[Bob Gezelter]

On Wednesday, August 19, 2015 at 8:52:09 AM UTC-4, Simon Clubley wrote:
> 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

Simon,

My point, which I may not communicated well, is (and was) two fold:

- spinning while checking IOSB contents has never been a good idea
- IOSB checking following a system call (e.g., $SYNC, $WAITx) OR receiving an AST is safe BECAUSE both operations represent the start of a basic block. 

An out-of-line call should force the code generator to invalidate all presumptions about local copies of variables (this is not specific to any one individual architecture). 

The section cited from the Alpha ARM (which I quoted in an earlier post) refers to system-state related transitions, not to in user-state calls.

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