Subject: hpff-doc: Asynchronous I/O

From: <[email-masked]> (Henry Zongaro)
Date: Mon, 16 Sep 1996 19:53:31 -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.
---------------------------------------------------------------------------
Hi Larry,

     I have the following comments on Asynchronous I/O.  These are based on
the August 17 draft - my apologies if these have changed or have been
corrected in the latest draft.

 - On p. 202, the text "If an ID= specifier appears, then . . . " appears
   twice - once as a constraint under H1101, and once just below.

 - On p. 202, the paragraph that begins "The addition of the ID= specifier",
   there are some typos "an WAIT" -> "a WAIT"; "specifing" -> "specifying"
   "an data transfer" -> "a data transfer".

 - The last paragraph from the bottom of p. 202, it's not clear from the
   description whether the transfer to the "ERR=" label is permitted to occur
   asynchronously.

 - On p. 203, the paragraph that begins "In the portion. . . " needs to be
   tightened up to prohibit references to entities that are associated with
   entities appearing in the data transfer statement from being referenced.
   For example,

          equivalence (i,j)
          read (99, id=id, rec=1) i
            i = 1         ! Currently prohibited
            j = 1         ! Not currently prohibited
          wait (99, id=id)

   Also, things like deallocating an allocatable array that appeared in the
   I/O list must be prohibited, changing the association of a pointer, etc.

 - On p. 203, the paragraph that begins "In the portion. . . " states that
   "no entity appearing in an expression anywhere in the input/output list
    may be assigned to or accessed."  This may be overly restrictive.  For
   example, it prohibits program fragments like the following, since "I" is
   referenced before the associated WAIT.

           do I = 1, 10
             read (99, id=ID(I), rec=I) A(:,I)
           end do
           ! do some other stuff
           do I = 1, 10
             wait (99, id=ID(I))
           end do

 - On p. 203, the last sentence of the paragraph that begins "Multiple
   outstanding. . . " states "If two WRITE statements which specify the same
   record number are executed, then the program is non-conforming."  This needs
   to indicate that this is only non-conforming if there is no intervening
   WAIT associated with the first WRITE.

 - On p. 203, the paragraph that begins "Note:  we still permit. . . "
   indicates that things like the following are legal:

        READ(10, ID=ID, REC=10), I, A(I)

   If we permit this, then things like this would be legal:

        READ(10, ID=ID, REC=10), I, (A(J), J = 1, I)

   which means that the number of entries (and their addresses) that need to be
   read isn't known up front.  It can be argued that the evaluation of the
   I/O list can be performed asynchronously, but then that runs into things
   like this:

        J = 1
        READ(10, ID=ID, REC=10), I, A(J+I)
        J = 100
        WAIT(10, ID=ID)

   This in turn leads to requiring the restriction that I argued against two
   comments ago.  I think we should avoid permitting references to variables
   that are being defined elsewhere in the same I/O list.

 - On p. 203, the constraint below H1103 can't be a constraint, since it can't
   be checked at compile-time.

 - On p. 203, the paragraph that begins "The DONE= specifier. . . ", the term
   scalar-default-logical-variable should be in italics.

Thanks,

Henry
---------------------------------------------------------------------------
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>
---------------------------------------------------------------------------