Subject: hpff-doc: New draft of io-ext.tex

From: <[email-masked]> (Henry Zongaro)
Date: Mon, 7 Oct 1996 17:44:38 -0400 (EDT)

---------------------------------------------------------------------------
[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.
---------------------------------------------------------------------------
Hello,

     My apologies to all for my tardiness on this.  There are still some
issues to be resolved:

   - If the IOSTAT= or ERR= appeared on an asynchronous data transfer, and an
     error occurs, is the user still required to have a matching WAIT?

   - Are there restrictions on the scope in which a WAIT statement is permitted
     to appear?  Must it appear in the same scope in which the asynchronous
     data transfer statement appeared?

   - What exactly was intended by the motion that called for asynchronous
     I/O to have the same behaviour as synchronous I/O?  Did it clarify that
     we want to permit things like:

           READ (99,ID=ID,REC=IREC) I, A(I)

     What about function references?

Thanks,

Henry

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% 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}

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 the second paragraph of section 9.2.1, before ``and'' add
``a processor-dependent set of allowed {\bf transfer methods},''.

To section 9.3.4, Rule R905, add

\BNF
connect-spec             \IS  ASYNCH = scalar-default-char-expr
\FNB

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

The {\em scalar-default-char-expr} shall evaluate to YES or NO.  YES specifies
that asynchronous data transfer statements are permitted for this connection.
NO specifies that asynchronous data transfer statements are not permitted
for this connection.  The value specified shall be in the set of transfer
methods permitted for the file.  If this specifier is omitted, the default
value is NO.

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 add the constraint

\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}

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 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 must
be direct and unformatted.

The {\tt ID=} specifier must not be specified for a unit opened with an
{\tt ASYNCH=} specifier with a value of NO.

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

For an asynchronous data transfer, errors
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 transfer
of an input/output statement that contains neither
an {\tt IOSTAT=} nor an {\tt 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.

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

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.
A {\tt WRITE} statement with an {\tt ID=} specifier must not specify both
the same unit and record number as any {\tt WRITE} statement with an {\tt ID=}
specifier for which the matching {\tt WAIT} statement has not been executed.

\begin{users}
Note: we still permit left-to-right definition of the I/O list on a READ.
This means that a statement like
\CODE
READ(10,ID=IDNUM,REC=10) I,A(I)
\EDOC
is legal and has the same semantics as a synchronous READ.
\end{users}

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

Add a new section 9.4.7:

{\bf 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 A {\em wait-spec-list} shall contain exactly one {\tt ID=} specifier
and at most one of each of the other specifiers.
\end{constraints}

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

The {\tt WAIT} statement terminates an asynchronous data transfer.
The {\tt IOSTAT=}, and {\tt ERR=} specifiers 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, the
{\em 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.}.

\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 store the results of the transfer, then
supplying the results to the matching 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>
---------------------------------------------------------------------------

---

From: Alok Choudhary <[email-masked]>
Date: Tue, 15 Oct 1996 14:20:58 -0500 (CDT)

It is a delayed response but I will just tell you what we had discussed
and agreed.

Yes, because there is no way to know that error will occur so the wait
must be present. Since, between the statement and wait, no variable
affected by asynch I/O be touched, there are no side effects.

>      data transfer statement appeared?

Yes, this restriction is requrired

>            READ (99,ID=ID,REC=IREC) I, A(I)

In our discussion we agreed that as long as the effect is the same as
synchronous I/O, there is no reason for it to be restricted. So, one could
perform large reads and then redistribute data accroding to the index.

SO, we agreed that we will permit this.

>      What about function references?

I dont remember this!

Alok

Northwestern Univ
Technological Institute
2145 Sheridan Road
Evanston, Illinois  60208-3118

phone:  (847) 467-4129. fax  :  (847) 491-4455
email: [email-masked] 
URL  : http://web.ece.nwu.edu/~choudhar
-------------------------------------------------------------------------