From jls@uxb.liv.ac.uk Mon Feb 1 13:49:49 1993 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA15950 (5.65c8/IDA-1.4.4j for ); Mon, 1 Feb 1993 14:50:45 +0100 Received: from mail.liv.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Mon, 01 Feb 93 13:50:06 GMT Received: from uxb.liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <04037-0@mailhub.liverpool.ac.uk>; Mon, 1 Feb 1993 13:49:59 +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 13:49:50 GMT Message-Id: <18610.9302011349@uxb.liv.ac.uk > Subject: HPF 1.0 comments on chapter 3 To: hpff-comments@edu.rice.cs Date: Mon, 1 Feb 93 13:49:49 GMT Cc: SC22WG5@dkuug.dk (SC22/WG5 members), UKFORTRAN@edinburgh.ac.uk (UK Fortran Panel) X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Here are my comments on chapter3 Comment on HPF 1.0, Jan'93 Chapter 3, Data Alignment and distribution It is a mistake to allow Fortran 90 attributes to appear mixed in HPF directives with HPF attributes. Fortran 90 attributes either specify properties of the data objects that determine the data semantics or they control or restrict the syntactic contexts where such data objects may appear, or both. The Fortran 90 attributes, except where they merely confirm what would otherwise be implicitly declared properties, cannot be ignored or removed without changing the program both sytactically and semantically. The HPF directive attributes are supposed to be ignorable without any such effect. Mixing these attributes is highly undesirable. This is particularly true if the stated intent of possible removal of the comment character in a later revision of Fortran is to be taken seriously. In such a case the duplication of Fortran 90 attributes in both Fortran 90 statements and HPF directives would mean such programs would end up with illegal duplicate declaration of attributes once the comment directive-origin was removed. As I remarked in a previous comment I think there to be quite cogent arguments for retaining the comment/directive nature even in a formal standard incorporating HPF in a future revision. However, I think there are very good reasons for not allowing duplicate specification of attributes unless there are very strict rules about the identity of all such specifications. Fortran has traditionally adopted the policy of disallowing duplicate specification rather than attempting to define what could be quite complex identity rules. Fortran 90 attributes should not be permitted within HPF directives except for the declaration of PROCESSORS and TEMPLATE, nor should template and processor entity names be permitted in Fortran 90 declarations. Finally, this chapter appears to be relatively well thought out and defined for arrays of elements which are considered to be "atomic" scalars. It is clear that this extends without problem to arrays of structure objects where the structure objects are also treated as indivisible. It is not clear to me however (this may be due to an inadequate reading of the text on my part) if distribution and/or alignment is applicable to the components of a structure. For instance, it may be desirable to have all instances of a particular component of structures of a derived type on one processor and a different component on another processor. I could not see how this was to be achieved. It may be that this is considered to be outside the scope of HPF 1.0, but this capability will become important in the optimisation of the use of structures in MIMD environments. -- 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