From jls@uxb.liv.ac.uk Mon Feb 1 17:13:38 1993 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA22689 (5.65c8/IDA-1.4.4j for ); Mon, 1 Feb 1993 18:17:25 +0100 Received: from mail.liv.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Mon, 01 Feb 93 17:16:52 GMT Received: from uxb.liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <10033-0@mailhub.liverpool.ac.uk>; Mon, 1 Feb 1993 17:13:45 +0000 From: "Dr.J.L.Schonfelder " Received: from uxb.liv.ac.uk (uxf.liv.ac.uk) by uxb.liv.ac.uk; Mon, 1 Feb 93 17:13:39 GMT Message-Id: <19308.9302011713@uxb.liv.ac.uk > Subject: Comments on HPF 1.0 chapter 4 To: hpff-comments@cs.rice.edu Date: Mon, 1 Feb 93 17:13:38 GMT Cc: SC22WG5@dkuug.dk (SC22/WG5 members) X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Comment on HPF 1.0, Jan'93 Chapter 4, Statements Firstly, there are a couple of trivial errors in this chapter that should be corrected. 1. The statement near the end of paragraph one on page 49 that user-defined functions on an array may not be called in a Fortran 90 array assignment, is not strictly true. a= fun(a) is perfectly valid provided fun(a) returns an array of the same shape as a and that the types are assignment compatible. Otherwise the manipulation of the elements of a performed by the function is essentially unconstrained. Presumably this is not what the sentance had in mind. It is therefore misleading at best and wrong at worst. 2. The assignment of the pointer in the butterfly example is in error since the interger array b has not been declared as a TARGET. The declaration should read INTEGER,TARGET :: b(n) More seriously, I think the syntax or the formal semantics of the FORALL statement is deficient. The non-terminal forall-assignment resolves to the non-terminal assignment-stmt. This is defined in section 7.5 of the Fortran 90 standard as variable = expr and variable is scalar-variable-name or array-element-name or subobject subobject is array-element or array-section or structure-component or substring In the explanation only array-element and array-section are mentioned however no syntactic constraint or semantic restriction expresses this. From the examples, it is clear that forall-assignment allows only a restricted class of variable and this should be expressed clearly in the specific syntax or constraints for the statement. For example, I assume a FORALL such as FORALL(i=1:n) x=i is intended to be illegal but I cannot see where this is prohibited by the current syntax. As I interpret the intent the left hand sides of the assignments must be such that the set of index values selects a set of non-overlapping objects to which values (be they data values or descripter values) calculated by the expr will be assigned, the assignments being done in no defined order. Neither the syntax nor the subsequent evaluation description ensures this although it is implied by the examples and the text of 4.1.5. However this text is not sufficiently precise to constitute a formal definition. The first example on page 52, FORALL (i=1:n, j=1:n, y(i,j).NE.0.0) x(i,j)=1.0/y(i,j) is equivalent to WHERE(y(1:n,1:n)/=0.0) x(1:n,1:n)=1.0/y(1:n,1:n) or WHERE(y/=0.0) x=1.0/y if x and y were both nxn arrays. It would probably be more consistent to state this. The concept of a pure procedure has significance over and above its relevance for optimisation on MIMD machines. The declaration of a procedure to be pure places restrictions on the code that may appear in the body of such a procedure and many of these restrictions could be checked by the compiler. The presence or absence of the pure directive is therefore quite unlike the memory management directives. The pure directive has both syntactic and semantic consequences. A pure function may be used in certain contexts where a impure function may not, and hence this is delcaring a syntactically and semantically significant attribute of the function. For this reason I believe it to be inappropriate for this to be declared by a comment/directive. The PURE attribute is similar to the RECURSIVE attribute and like this would be better introduced as a specification on the procedure heading. Also like RECURSIVE it is inappropriate to declare this inside the body of the function where all other declarations of the function name are establishing the properties of the result variable and only indirectly those of the procedure. PURE and RECURSIVE are properties of the procedure not of its result. It would be better to extend R1217 of Fortran 90 to allow PURE as another prefix terminal, and rule R1220 to allow PURE as an alternative to RECURSIVE. Given that a PURE procedure may not modify pointer associations there is no reason to allow pointer dummy arguments. With this restriction I would have thought the constraints on a PURE function could be more simply expressed as: i) all dummy variables must be INTENT(IN), ii) all dummy procedures must be PURE, iii) no global variable may be redefined, iv) no global pointer may have its association status changed, v) no local variable may have the SAVE attribute, vi) any procedure invoked must be PURE, and vii) no I/O, STOP, PAUSE, ALLOCATE, NULLIFY, or DEALLOCATE statements may be executed, (plus of course the constraints implied on the memory management directives that can apply.) I think this set of constraints is sufficient to ensure that a function has no side effects and that its only effect is to deliver a result whose value is determined by its arguments and/or the state of the global data environment. The only difference for a PURE subroutine would then be that it could modify the values of its INTENT(OUT) or INTENT(INOUT) arguments, or the association status of any pointer dummy arguments. Again I think the choice of comment directive for the INDEPENDENT qualifier is a mistake. Such a loop is syntactically and semantically restricted. For instance, almost trivially an independent loop must be an index loop and must not contain any EXIT statements. As with the PURE specification, this sort of qualifier which has syntactic implications would be better done via language syntax. An independent loop is a very special class of indexed loop and as such would be better introduced by a loop qualifier that could not be separated from the loop it qualifies. Also the use of a single directive to qualify a number of nested loops in one directive appears to be an undesirable shorthand. There would be no reason why there could not be substantial amounts of code between the DO i1.. and the subsequent DOs all of which are being declared as independent by the single directive. It would be much simpler and less prone to confusion if the qualifier was always attached to the individual DO statements. In such a case there would be no need to specify the index variable that would always be that of the DO loop and any NEW variables could simple be named in a parenthetical list following the qualifier. For example, DO i=1,100 :INDEPENDENT or DO i1=1,n1 :INDEPENDENT DO i2=1,n2 :INDEPENDENT(v1,v2,u1,u2) N.B. the extra : punctuation. Something like this is necessary to preserve syntactic determinism in the old fixed source form where blanks remain insignificant. Also the specification of the variables v1 etc. to be new each iteration has syntactic implications. They must be defined withing the body of the loop before they are referenced, and similarly they must be defined again after the exit before they are referenced again. These syntactic restrictions are of a similar character to the TARGET attribute. A processor does not have to make use of the information and there will be no change in the semantics of the program as a result, but if the processor does then the program may run faster. However, the asssertion restricts the nature of the code and the contexts in which certain quantities may appear. This is further argument favouring syntax not pseudo comment directives for INDEPENDENT. -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk