Subject: hpff-doc: io-ext.tex

From: Larry Meadows <[email-masked]>
Date: Tue, 28 May 1996 13:01:37 -0700 (PDT)

---------------------------------------------------------------------------
[email-masked] is a mailing list for HPF 2.0 language specification
authors and editors.  Instructions for adding or deleting yourself from this
list appear at the bottom of this message.
---------------------------------------------------------------------------

% File: io-ext.tex

% Contents:
% Approved Extension for EXTRINSIC(HPF_LOCAL) for HPF 2.0 document

% Revision history:
% May-28-96	Created by Larry Meadows, The Portland Group

\chapter{Approved Extension for Asynchronous I/O}
\label{ch-io-ext}

{\em
Comments on this chapter should be directed to 
{\tt [email-masked]}.
Please use ``{\tt Comments on Asynch I/O}'' as the {\tt Subject:}
line.
\par
}

This section defines a mechanism for performing Asynchronous I/O
from an HPF or Fortran program. These are presented as changes
to the Fortran 90 standard.

To section 9.4.1, Rule R912, add

                                                                        \BNF
io-control-spec            \IS ID = scalar-default-int-variable
                                                                        \FNB

To section 9.4.1, Rule R912 constraints add

\begin{constraints}

\item If an {\tt ID=} specifier appears, then no function reference may appear
in an expression anywhere in the data transfer statement.

\end{constraints}

To section 9.7, add the following text:

If an {\tt ID=} specifier appears, then no function reference may appear
in an expression anywhere in the data transfer statement.

At the end of section 9.4.1, add the following paragraph:

The addition of the {\tt ID=} specifier results in the initiation of an
asynchronous data transfer.  The data transfer statement must be
eventually followed by an {\tt WAIT} statement specifing the same
{\tt ID} value that was returned to the {\tt ID} variable in an data transfer
statement.  This {\tt WAIT} statement is called the
matching {\tt WAIT} statement. Note that asynchronous data transfer must
be direct and unformatted.

Insert the following text at the end of section 9.4.3 before the
final paragraph:

For an asynchronous data transfer, errors or end-of-file conditions
may occur either during execution of the data transfer statement or
during subsequent data transfer.  Should these conditions not
result in termination of the program then these conditions will
be detectable by the programmer via {\tt ERR=} and {\tt IOSTAT=}
specifiers in the matching {\tt WAIT} statement.

Alter the paragraph at the end of 9.4.3 to read as follows:

Execution of the executable program is terminated if an error condition
occurs during execution or during subsequent data tranfer
of an input/output statement that contains neither
an {IOSTAT=} nor an {ERR=} specifier.

Should an asynchronous data transfer statement cause the {\tt ERR} or
{\tt IOSTAT}
variables to be set then any matching
{\tt WAIT} statement will do the same.

To section 9.4.4, alter operation 8 to read as follows:

\begin{itemize}

\item  (8) Cause any variables specified in the {\tt IOSTAT=},
{\tt SIZE=} and
{\tt ID=| specifiers to become defined.

\end{itemize}

To section 9.4.4, add the following three paragraphs:

For asynchronous data transfers steps 1-8 correspond to both
the asynchronous data transfer statement and the matching {\tt WAIT}
statement.  Steps 4-7 may occur asynchronously with program
execution.  If an implementation does not support asynchronous
data transfers then steps 1-8 may be performed by the asynchronous
data transfer statement,  the matching {\tt WAIT} statement must still
be executed, the only effect being to return status information.

In the portion of the program which executes between the asynchronous data
transfer input/output statement and the matching {\tt WAIT},
no entity appearing
in an expression anywhere in the input/output list may be assigned to
or accessed.

Multiple outstanding asynchronous data transfer operations are allowed
but they must all be reads or
writes. No other I/O statements on the same unit are allowed until all
{\tt WAIT} requests are satisfied.
If two {\tt WRITE} statements which specify the same
record number are executed, then the program is non-conforming.

Advice to users:

Note: we still permit left-to-right definition of the I/O list on a READ.
So READ(10,ID=5,REC=10) I,A(I) is legal and has the same semantics as a
synchronous READ ]

End advice to users.

To section 9, change "and {\tt INQUIRE} statements" to
", {\tt INQUIRE}, and {\tt WAIT} statements".

Add a new section 9.4.7:

9.4.7 WAIT statement
                                                                        \BNF

        WAIT statement \IS WAIT (wait-spec-list)
        wait-spec \IS ID = scalar-default-int-expr
                  \OR ERR = label
                  \OR IOSTAT= label
                  \OR DONE=scalar-default-logical-variable
                                                                        \FNB

\begin{constraints}

\item The {\tt ERR=} and {\tt IOSTAT=} specifiers may only be present
if they were present in the matching asynchronous
data transfer statement.

\end{constraints}

The {\tt WAIT} statement terminates an asynchronous data transfer.
The {\tt ID=} specifier must be present
The {\tt IOSTAT=}, and {\tt ERR=} specifiers are optional and are described in
sections 9.4.1.4, 9.4.1.5 and 9.4.1.6, respectively.

The {\tt DONE=} specifier is optional. If present, then the
scalar-default-logical-variable is set to {\tt .TRUE.} if the asynchronous
operation is complete, and to {\tt .FALSE.} if it is not complete.

The {\tt WAIT} statement causes the processor
to wait until the matching data transfer statement terminates,
either normally, or with an error condition. After execution
of the matching {\tt WAIT} statement, error conditions, control transfer,
data transfer, and the value of any {\tt IOSTAT=} variable are as if the
data transfer statement had been executed synchronously in place of the
matching {\tt WAIT} statement, and with the addition of any {\tt IOSTAT=}
and {\tt ERR=},
specifiers to the {\it io-control-spec-list} of the data transfer
statement.

If the {\tt DONE} specifier is present, and the returned value is
{\tt .FALSE.}, than one
or more matching {\tt WAIT} statement must be executed, until either the
{\tt DONE=} specifier is not present, or the returned value is {\tt .TRUE.}

Advice to implementors:

Implementors may choose to implement any or all asynchonous I/O
synchronously. This essentially means using the ID= clause on the
data transfer statement to store the results of the transfer, then
supplying the results to the matching WAIT statement.

End advice to implementors.
---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------