Subject: hpff-doc: yet another final ASYNCH

From: Larry Meadows <[email-masked]>
Date: Tue, 17 Dec 1996 09:40:50 -0800 (PST)

---------------------------------------------------------------------------
[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
% 1996/10/07    Updated by Henry Zongaro
% 1996/10/18    Updated by Henry Zongaro
% 1996/12/10    Updated by Larry Meadows

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

This section defines a mechanism for performing Asynchronous I/O
from an HPF or Fortran program. These are presented as changes
to the Fortran 95 proposed draft standard, X3J3/96-007r1.
This extension is a subset of the proposed X3J3
Asynchronous I/O extension, paper X3J3/96-158r2. Briefly, this extension
allows direct unformatted data transfers to be performed
asynchronously with program execution. The {\tt WAIT} statement can be used
to wait for the data transfers to complete. The {\tt INQUIRE} statement
can be used to determine if the data transfers are complete.

To section 9.3.4, rule R905 {\it connect-spec}, add

\begin{quote}
                                                                         \BNF
                         \OR  ASYNCHRONOUS
                                                                         \FNB
\end{quote}

Add a new section after 9.3.4.10, entitled ``{\bf ASYNCHRONOUS specifier in the
OPEN statement}'', containing the following paragraphs:

\begin{quote}
If the {\tt ASYNCHRONOUS} specifier is specified for a unit
in an {\tt OPEN} statement, then {\tt READ} and {\tt WRITE}
statements for that
unit may include the {\tt ASYNCHRONOUS} specifier in the control information
list.

The presence of an {\tt ASYNCHRONOUS} specifier in a {\tt READ}
or {\tt WRITE}
statement permits (but does not require) a processor to perform the
data transfer asynchronously. The {\tt WAIT} statement is used to
wait for or inquire as to the status of asynchronous input/output
operations.
\end{quote}

To section 9.4.1, rule R912 {\it io-control-spec}, add

\begin{quote}
                                                                        \BNF
                           \OR ID = scalar-default-int-variable
                           \OR ASYNCHRONOUS
                                                                        \FNB
\end{quote}

and also add the constraints

\begin{quote}
\begin{constraints}

\item If either an {\tt ASYNCHRONOUS} or an {\tt ID=}
 specifier is present, then both shall be present.

\item If an {\tt ASYNCHRONOUS} specifier is present, the {\tt REC=} specifier
shall appear, a {\em format} shall not appear, and a {\em namelist-group-name}
shall not appear.

\item If an {\tt ASYNCHRONOUS} specifier is present, then no function
reference may
appear in an expression anywhere in the data transfer statement.

\end{constraints}
\end{quote}

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

\begin{quote}

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

The matching {\tt WAIT} statement shall be executed in the same instance of
the same subprogram in which the asynchronous data transfer statement
was executed.

\begin{implementors}
The above restriction is to prevent the compiler from performing code
motion optimizations across {\tt WAIT} statements. Any operations involving
variables listed in asynchronous input/output lists must be performed
after the matching {\tt WAIT} statement is executed.
\end{implementors}

No {\tt ASYNCHRONOUS} specifier nor any {\tt ID=} specifier shall be specified
if the {\tt io-unit} was not opened with the {\tt ASYNCHRONOUS} specifier.
\end{quote}

In section 9.4.1, in the fourth and fifth paragraphs after the constraints,
change both instances of ``{\tt IOSTAT=} or a {\tt SIZE=}'' to
``{\tt IOSTAT=}, {\tt SIZE=}, or an {\tt ID=}''.

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

\begin{quote}
For an asynchronous data transfer, errors
may occur either during execution of the data transfer statement or
during subsequent data transfer. If these errors occur during the data
transfer statement and do not result in termination of the program,
then they will be detectable using
{\tt ERR=} and {\tt IOSTAT=} specifiers in the data transfer statement.
If these error conditions occur during subsequent data transfer and
do not result in termination of
the program, then they will be detectable using
{\tt ERR=} and {\tt IOSTAT=} specifiers in 
the matching {\tt WAIT} statement.
\end{quote}

In the paragraph at the end of section 9.4.3, change the first occurrence
of ``execution'' to read ``execution or subsequent data transfer.''

To section 9.4.4, add the following paragraphs:

\begin{quote}
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 shall still
be executed, the only effect being to return status information.

Any variable that appears as an {\em input-item} or {\em output-item}
in an asynchronous data transfer statement, or that is associated with
such a variable,
shall not be referenced, become defined, or become undefined
until the execution of the matching {\tt WAIT} statement. However, it
is allowed for a pointer to become associated with such a variable.

Multiple outstanding asynchronous data transfer operations ({\tt READ} or
{\tt WRITE}) are allowed; however, no two {\tt WRITE} operations may
use the same unit and record number without an intervening {\tt WAIT}.
\end {quote}

\begin{users}
HPF permits left-to-right definition of the I/O list on a {\tt READ},
whether or not it is asynchronous.
This means that a statement such as
\CODE
READ(10,ID=IDNUM,REC=10) I,A(I)
\EDOC
is conforming and has the same input behavior as a synchronous {\tt READ}.
\end{users}

In section 9, change ``and {\tt INQUIRE} statements'' to
``, {\tt INQUIRE}, and {\tt WAIT} statements''.

In section 9.6.1.14, add the following sentence as the last sentence of
the paragraph:

\begin{quote}
If there are outstanding data transfer operations for the specified unit, the
value assigned to the {\tt NEXTREC=} specifier is computed as if all the
outstanding data transfers had already completed, in the order in which
they were issued.
\end{quote}

To section 9.6.1, rule R924 {\it inquire-spec}, add
\begin{quote}
                                                                         \BNF
                         \OR  ID = scalar-default-int-variable
                         \OR  PENDING = scalar-default-logical-variable
                                                                         \FNB
\end{quote}

and also add the constraints

\begin{quote}
\begin{constraints}

\item The {\tt ID=} and {\tt PENDING=} specifiers shall not appear in an
{\tt INQUIRE}
statement if the {\tt FILE=} specifier is present.

\item If either an {\tt ID=} specifier or a {\tt PENDING=} specifier
is present, then both shall be present.

\end{constraints}
\end{quote}

Add a new section after 9.6.1.22, entitled ``{\bf ID= and PENDING= specifiers
in the INQUIRE statement}'',
containing the following paragraph:
\begin{quote}
If an {\tt ID=} specifier is present in an
{\tt INQUIRE} statement, then the variable
specified in the {\tt PENDING=} specifier is assigned the value true if the
data transfer identified by the {\tt ID=} specifier for the specified unit has
not yet completed. In all other cases, the variable specified in the
{\tt PENDING=} specifier is set to false.
\end{quote}

\section{WAIT statement}
                                                                        \BNF

        WAIT statement \IS WAIT (wait-spec-list)
        wait-spec \IS UNIT = io-unit
                  \OR ID = scalar-default-int-expr
                  \OR ERR = label
                  \OR IOSTAT = label
                                                                        \FNB

\begin{constraints}
\item A {\em wait-spec-list} shall contain exactly one {\tt UNIT=} specifier,
exactly one {\tt ID=} specifier,
and at most one of each of the other specifiers.
\end{constraints}

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

\begin{implementors}
Implementors may choose to implement any or all asynchronous I/O
synchronously. This essentially means using the {\tt ID=} clause on the
data transfer statement to record the results of the transfer, then
supplying the results to the matching {\tt WAIT} statement.
\end{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>
---------------------------------------------------------------------------