From elustond@almaden.ibm.com Mon Mar 15 19:16:30 1993 Received: from almaden.ibm.com by cs.rice.edu (AA12275); Mon, 15 Mar 93 19:16:30 CST Message-Id: <9303160116.AA12275@cs.rice.edu> Received: from almaden.ibm.com by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3598; Mon, 15 Mar 93 17:16:52 PST Date: Mon, 15 Mar 93 17:14:16 PST From: elustond@almaden.ibm.com To: hpff-comments@cs.rice.edu Subject: formal semantics OPTIONS: ACK LOG SHORT NOTEBOOK CSNET Date: 14 March 1993, 11:39:20 PST From: Pablo Elustondo 8-457-1818 ELUSTOND at ALMADEN To: hpff-comments at cs.rice.edu Subject: Hi, May I ask you a question related to HPF?. I have been working on the definition of a parallel language very close to FortranD/HPF called DPF (Frontiers 92). It was a joint project between IBM Almaden Research Center and IBM Argentina. The semantic definition of DPF has been formalized to some extent. I would like to apply our semantic model to contribute to the formalization of HPF semantics. Could you send me good references about the subject? Do you know people working on that?. Thank you in advance, Pablo Elustondo Foundations of Mass. Par. Comput. Almaden Research Center. From vas@watson.ibm.com Wed Mar 24 14:36:23 1993 Received: from watson.ibm.com by cs.rice.edu (AA18767); Wed, 24 Mar 93 14:36:23 CST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8581; Wed, 24 Mar 93 15:36:25 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 0901; Wed, 24 Mar 1993 15:36:15 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Wed, 24 Mar 93 15:36:15 EST Received: from basho.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA34741; Wed, 24 Mar 93 15:36:15 -0500 Received: by basho.watson.ibm.com (AIX 3.1/UCB 5.61/900524) id AA16049; Wed, 24 Mar 93 15:36:28 -0500 Date: Wed, 24 Mar 93 15:36:28 -0500 From: vas@watson.ibm.com (Vasanth Bala) Message-Id: <9303242036.AA16049@basho.watson.ibm.com> To: hpff-comments@cs.rice.edu Subject: allocatable arrays HPF allows ALIGN operations on allocatable arrays, with the rule that the alignment definition "only takes effect at the point where the arrays are created, not where they are declared" (pg. 33 of HPF v1.0 manual). But if you take the example listed there, and flip the two allocate statements for A and B, it produces an ambiguous situation: subroutine millard_fillmore (n, m) real, allocatable (:) :: A, B align B(i) with A(i+n) distribute A(block(m*2)) allocate (B(13)) ... B(i) = B(i-1) + B(i+1) ... allocate (A(27)) ... B(i) = B(i-1) + B(i+1) return end What is the distribution of B at statement ?? The distribution of B at stmt is clear, because the moment A and B are both allocated, the alignment is clear. Also, if A is allocated before B, there is no problem. But if B is allocated before A as shown above, it is unclear what the distribution of B should be. -Vas From u570409@beta.lanl.gov Mon Mar 29 17:16:46 1993 Received: from p.lanl.gov by cs.rice.edu (AA06974); Mon, 29 Mar 93 17:16:46 CST Received: from beta.lanl.gov by p.lanl.gov (5.65/1.14) id AA19680; Mon, 29 Mar 93 16:16:45 -0700 Received: by beta.lanl.gov (5.57/Ultrix2.4-C) id AA11954; Mon, 29 Mar 93 16:15:48 -0700 Date: Mon, 29 Mar 93 16:15:48 -0700 From: u570409@beta.lanl.gov (Harry E. Bell) Message-Id: <9303292315.AA11954@beta.lanl.gov> To: hpff-comments@cs.rice.edu Subject: HPFF Spec. Cc: u570409@beta.lanl.gov Please notify me when version 1.0 of the High Performance Fortran Language Specification is complete and how to obtain a copy. Thank you. Harry Bell, MS:A5-10 DOE Field Office, Richland P. O. Box 550 Richland, WA 99352 u570409@beta.lanl.gov From jim@meiko.co.uk Mon Apr 5 09:45:32 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA01357); Mon, 5 Apr 93 09:45:32 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA08698 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Mon, 5 Apr 1993 15:45:30 +0100 Date: Mon, 5 Apr 1993 15:45:30 +0100 From: James Cownie Message-Id: <199304051445.AA08698@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA00333; Mon, 5 Apr 93 15:41:34 BST To: hpff-comments@cs.rice.edu Subject: Minor typos Content-Length: 690 In version 1.0 ("processed by LaTex 1 April), I have noticed the following typographical features. Page 20. Line 19: "that column 6 is be blank," should (presumably) read "that column 6 must be blank" Either the example on lines 25-31 is incorrect, or the statement on line 8 is incorrect. (The example must NOT start !HPF if it is to be used in fixed form format, the example is not therefore universal). -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From schreibr@riacs.edu Tue Apr 13 12:46:12 1993 Received: from icarus.riacs.edu by cs.rice.edu (AA24312); Tue, 13 Apr 93 12:46:12 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA03567; Tue, 13 Apr 93 10:46:10 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA00954; Tue, 13 Apr 93 10:45:31 PDT Message-Id: <9304131745.AA00954@thor.riacs.edu> Date: Tue, 13 Apr 93 10:45:31 PDT From: Rob Schreiber To: hpff-comments@cs.rice.edu Subject: Chapter 3 Chapter 3: I like the new writeups and additional explanations. But I would like to suggest some changes for additional clarity: page 43:, line -5: "... specifies that a dummy argument should be aligned to a copy of the template of the corresponding actual argument in the wame way that the actual argument is aligned." page 44: line 2: (in a) may ... take out the "in a" page 44: lines 4--5. I think the restriction against general expression actuals with inherited dummies is so severe it makes the use of inherit in library routines impossible. Instead, I think we can use the following theory. a. It is allowed. b. Every actual argument has a describable mapping, and hence it is ultimately aligned to some template (of the compiler's choosing if it is not an array or regular section of an array). This includes sections like A(INDEX_VECTOR), which must, therefore, be moved to a temporary. page 44, line 8: type "mappoing" lines 7--9: I thought that INHERIT is out of SS HPF anyway! Just before Section 3.10: An example would be very good here. Like: REAL DOUGH(100) !HPF$ DISTRIBUTE DOUGH(BLOCK(10)) CALL PROBATE( DOUGH(7:23:2) ) ... SUBROUTINE PROBATE(BREAD) REAL BREAD(9) INHERIT BREAD the inherited template of BREAD has shape [100]; BREAD(I) is aligned with element 5 + 2*I of it and, since BREAD does not appear in a prescriptive DISTRIBUTE directive, it has a BLOCK(10) distribution. Page 45, just after the inner itemized list. This comment applies to the three cases above, not the three bulletted cases above that. So it should indent at the level of the bulleted items. Better to say "in these three cases ... " page 45, line -2: I think this is clearer: "Therefore the template of TANGO is a copy of the 128 element template of the whole array TWIST. TANGO(I) is aligned with element 3*I of it. It is mapped like this:" page 46, after the first diagram: You are slyly introducing the notion of the "pre-existing" mapping, one not otherwise possible in HPF, of the natural template of the dummy. This is a mapping that cannot be inherited (since then the natural template does not live) cannot be prescribed and cannot be described. DO you really want to deal with this idea in the draft -- it confused me for a bit, and I think it will confuse others. Can we say: "But the template of FOXTROT has the same size 14 as FOXTROT itself. THe actual argument, FRUG(1:40:3) is mapped to the 16 processors in this manner: Abstract Array processor elements ... ... It would be reasonable to understand the mapping of the template of FOXTROT to coincide with the layout of the array section, diagram but we shall shortly see that this is not permitted in HPF. Within subroutine TERPSICHORE it would be correct to make the descriptive assertion... " Page 47, lines 9ff. The thing in parens seems essential to me, so I suggest it be a separate, nonparenthetical paragraph. In the example, there is a missing asterisk: !HPF$ ALIGN FOXTRO(J) WITH *GURF(3*J-2) ------- Rob Schreiber From schreibr@riacs.edu Tue Apr 13 12:46:22 1993 Received: from icarus.riacs.edu by cs.rice.edu (AA24327); Tue, 13 Apr 93 12:46:22 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA03571; Tue, 13 Apr 93 10:46:20 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA00958; Tue, 13 Apr 93 10:45:40 PDT Message-Id: <9304131745.AA00958@thor.riacs.edu> Date: Tue, 13 Apr 93 10:45:40 PDT From: Rob Schreiber To: hpff-comments@cs.rice.edu Subject: Chapter 4 Chapter 4: 1. page 55. "with the value of 1" should be "with the value 1". 2. What are the constraints on the form of *scalar-mask-expr*? Is this okay? FORALL(I = 1:N, A(10,3) > 75) B(I) = 1776.00 This? FORALL(I = 1:N, J = 1:20, A(I,3) > 75) B(I,J) = 1812.00 3. The repeated use of "Advice to users" in the examples sections (4.1.3), (4.2.3), (4.4.3), and (4.4.1) is unnecessary and jarring. 4. The constraint of Section 4.3.1.1 permit: PURE FUNCTION KOELBEL(X) REAL X(:,:) INHERIT X DISTRIBUTE X (CYCLIC(4)) which should not be permitted. It is necessary to bar dummies from *prescriptive* mapping directives altogether. Descriptive mapping directives are okay. So is the inherit attribute. So is DISTRIBUTE * ONTO * (which is the default for a dummy with the INHERIT attribute.) Page 80. The discussion of NEW implies that the old private variables are not referenced after execution of the loop (they are dead) until they are redefined. This should be explicitly stated. Make it clear that it is as if the NEW variables are undefined following the loop, so it may not be correctly asserted that X is a NEW variable if its "last" value is referenced later. -------- Rob Schreiber From schreibr@riacs.edu Tue Apr 13 12:46:31 1993 Received: from icarus.riacs.edu by cs.rice.edu (AA24342); Tue, 13 Apr 93 12:46:31 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA03577; Tue, 13 Apr 93 10:46:29 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA00962; Tue, 13 Apr 93 10:45:50 PDT Message-Id: <9304131745.AA00962@thor.riacs.edu> Date: Tue, 13 Apr 93 10:45:50 PDT From: Rob Schreiber To: hpff-comments@cs.rice.edu Subject: Chapter 5 Chapter 5: I have redone MINLOC and MAXLOC to correct an off-by-one error. Should note that all new procedures are PURE. From schreibr@riacs.edu Tue Apr 13 12:46:41 1993 Received: from icarus.riacs.edu by cs.rice.edu (AA24358); Tue, 13 Apr 93 12:46:41 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA03586; Tue, 13 Apr 93 10:46:40 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA00966; Tue, 13 Apr 93 10:46:01 PDT Message-Id: <9304131746.AA00966@thor.riacs.edu> Date: Tue, 13 Apr 93 10:46:01 PDT From: Rob Schreiber To: hpff-comments@cs.rice.edu Subject: CHapter 6 Chapter 6: too many "is"s on page 135, l -7. Will someone read this for comprehensibility? It is often cryptic. From schreibr@riacs.edu Tue Apr 13 12:46:50 1993 Received: from icarus.riacs.edu by cs.rice.edu (AA24374); Tue, 13 Apr 93 12:46:50 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA03594; Tue, 13 Apr 93 10:46:50 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA00970; Tue, 13 Apr 93 10:46:12 PDT Message-Id: <9304131746.AA00970@thor.riacs.edu> Date: Tue, 13 Apr 93 10:46:12 PDT From: Rob Schreiber To: hpff-comments@cs.rice.edu Subject: Chapter 7 Chapter 7: Title: Storage and Sequence Association. Put all keywords and variable names in the text into tt font! I can take a shot if Mary gives me the draft for a day. p 143: line -14: sequentail From jim@meiko.co.uk Fri Apr 16 10:37:23 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09231); Fri, 16 Apr 93 10:37:23 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18749 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 16:37:18 +0100 Date: Fri, 16 Apr 1993 16:37:18 +0100 From: James Cownie Message-Id: <199304161537.AA18749@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01713; Fri, 16 Apr 93 15:32:57 GMT To: hpff-comments@cs.rice.edu Subject: Chapter 1 Content-Length: 324 Page 2: line 43 performace for performance -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From jim@meiko.co.uk Fri Apr 16 10:41:14 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09323); Fri, 16 Apr 93 10:41:14 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18774 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 16:41:12 +0100 Date: Fri, 16 Apr 1993 16:41:12 +0100 From: James Cownie Message-Id: <199304161541.AA18774@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01714; Fri, 16 Apr 93 15:36:55 GMT To: hpff-comments@cs.rice.edu Subject: Chapter 3 Content-Length: 495 Page 32: line 10 blank missing in "allalignees" Page 38: line 9 exmaple for example line 26 descritive for descriptive Page 44: line 2 "in a may only" should read "may only" line 8 mappoing for mapping -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From jim@meiko.co.uk Fri Apr 16 10:47:43 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09440); Fri, 16 Apr 93 10:47:43 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18793 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 16:47:41 +0100 Date: Fri, 16 Apr 1993 16:47:41 +0100 From: James Cownie Message-Id: <199304161547.AA18793@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01715; Fri, 16 Apr 93 15:43:24 GMT To: hpff-comments@cs.rice.edu Subject: Chapter 4 Content-Length: 959 Page 55: lines 19 and 20 There is a poor break here which leaves the full stop at the start of line 20 Page 56: line 36 "if and only if indx contains no repeated values" should read "if and only if indx(1:10) contains no repeated values" (The bounds of indx are not explicit in the example, and repeated values outside (1:10) would not make the example invalid). Page 61: line 32 "does not appear a syntactic constraint" should read "does not appear as a syntactic constraint". Page 77: line 19 Why not call the function mandel and avoid us having to work it out for ourselves ! Page 82: line 13 "neither loop would not be" should read "neither loop would be" -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From jim@meiko.co.uk Fri Apr 16 10:52:20 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09533); Fri, 16 Apr 93 10:52:20 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18825 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 16:52:17 +0100 Date: Fri, 16 Apr 1993 16:52:17 +0100 From: James Cownie Message-Id: <199304161552.AA18825@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01717; Fri, 16 Apr 93 15:47:59 GMT To: hpff-comments@cs.rice.edu Subject: Chapter 5 Content-Length: 754 Page 110: line 19 I disagree with the statement that the length "must" be of at least 10 characters. The treatment of these result character strings should be the same as those in INQUIRE statements, no size is specified for these strings, they are simply yhe subject of character assignments. If the user chooses to pass short strings, she gets the partial result. "Must" here implies that it is an error to pass a shorter string. I do not belive that this is so. -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From jim@meiko.co.uk Fri Apr 16 10:54:43 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09619); Fri, 16 Apr 93 10:54:43 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18857 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 16:54:40 +0100 Date: Fri, 16 Apr 1993 16:54:40 +0100 From: James Cownie Message-Id: <199304161554.AA18857@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01718; Fri, 16 Apr 93 15:50:23 GMT To: hpff-comments@cs.rice.edu Subject: Chapter 6 Content-Length: 474 Page 135: line 41 "one copy of the procedure is conceptually executing" should read "one copy of the procedure conceptually executing" Page 137:line 31 "exterinsic" should read "extrinsic" -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From jim@meiko.co.uk Fri Apr 16 11:01:46 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09801); Fri, 16 Apr 93 11:01:46 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18891 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 17:01:43 +0100 Date: Fri, 16 Apr 1993 17:01:43 +0100 From: James Cownie Message-Id: <199304161601.AA18891@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01719; Fri, 16 Apr 93 15:57:22 GMT To: hpff-comments@cs.rice.edu Subject: Chapter 7 Content-Length: 1193 Page 143: line 3-8 This explanation is incorrect. It is impossible to specify a mapping that would cause a single numeric storage unit to be split (other than by overlatying a character variable, which is forbidden in the standard). What we're trying to do is to ensure that no atomic variable is split. The problem being that (by definition in the standard) a variable of type COMPLEX or DOUBLE PRECISION occupies TWO numeric storage units, which we want to keep together on the same processor. This code does NOT split a numeric storage unit, but is what we're trying to forbid... DOUBLE PRECISION D(10) INTEGER I(20) EQUIVALENCE(I,D) !HPF$DISTRIBUTE I(CYCLIC) I think you need the "atomic variable" concept here as well to outlaw the above code. Page 145: line 37/38 "matches the dummy argument as the actual argument" should (I think !) read "matches both the dummy argument and the actual argument" -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From jim@meiko.co.uk Fri Apr 16 11:03:19 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09895); Fri, 16 Apr 93 11:03:19 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18909 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 17:03:16 +0100 Date: Fri, 16 Apr 1993 17:03:16 +0100 From: James Cownie Message-Id: <199304161603.AA18909@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01720; Fri, 16 Apr 93 15:58:51 GMT To: hpff-comments@cs.rice.edu Subject: Chapter 8 Content-Length: 460 Page 150: line 20 Removes the PROCESSOR_VIEW directive from the subset, BUT the PROCESSOR_VIEW directive is mentioned nowhere else in the document (I guess it went into the JOD !) -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From jim@meiko.co.uk Fri Apr 16 11:05:37 1993 Received: from hub.meiko.co.uk by cs.rice.edu (AA09995); Fri, 16 Apr 93 11:05:37 CDT Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk with SMTP id AA18927 (5.65c/IDA-1.4.4 for hpff-comments@cs.rice.edu); Fri, 16 Apr 1993 17:05:36 +0100 Date: Fri, 16 Apr 1993 17:05:36 +0100 From: James Cownie Message-Id: <199304161605.AA18927@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA01722; Fri, 16 Apr 93 16:01:18 GMT To: hpff-comments@cs.rice.edu Subject: Annex ! Content-Length: 490 Page 153: line 40 prtocedure should read procedure line 44 "(interface kind HPF_LOCAL." Should have a closing paren, so "(interface kind HPF_LOCAL.)" Page 156: line 38 subprogranm should read subprogram -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From Denis.Hugli@irisa.fr Thu Apr 29 07:15:52 1993 Received: from irisa.irisa.fr by cs.rice.edu (AA07695); Thu, 29 Apr 93 07:15:52 CDT Received: from illico.irisa.fr by irisa.irisa.fr; Thu, 29 Apr 1993 14:16:05 +0200 (5.65c8/93-04-21) Received: from russie.irisa.fr by illico.irisa.fr; Thu, 29 Apr 1993 14:15:55 +0200 (5.65c8/loc4.12) Date: Thu, 29 Apr 1993 14:15:55 +0200 From: Denis.Hugli@irisa.fr (Denis Hugli) Message-Id: <199304291215.AA05915@illico.irisa.fr> To: hpff-comments@cs.rice.edu Subject: chapter 3 X-Charset: LATIN1 X-Char-Esc: 29 Consider this HPF script : REAL A(8,8), B(8,8) !HPF$ PROCESSORS P(4) !HPF$ DISTRIBUTE A(CYCLIC,CYCLIC) ONTO P ... the expected mapping for A should be something like that : A 1 2 3 4 5 6 7 8 ----------------------------------------- 1 |P(1)|P(2)|P(3)|P(4)|P(1)|P(2)|P(3)|P(4)| ----------------------------------------- 2 |P(2)|P(3)|P(4)|P(1)|P(2)|P(3)|P(4)|P(1)| ----------------------------------------- 3 |P(3)|P(4)|P(1)|P(2)|P(3)|P(4)|P(1)|P(2)| ----------------------------------------- 4 |P(4)|P(1)|P(2)|P(3)|P(4)|P(1)|P(2)|P(3)| ----------------------------------------- 5 |P(1)|P(2)|P(3)|P(4)|P(1)|P(2)|P(3)|P(4)| ----------------------------------------- 6 |P(2)|P(3)|P(4)|P(1)|P(2)|P(3)|P(4)|P(1)| ----------------------------------------- 7 |P(3)|P(4)|P(1)|P(2)|P(3)|P(4)|P(1)|P(2)| ----------------------------------------- 8 |P(4)|P(1)|P(2)|P(3)|P(4)|P(1)|P(2)|P(3)| ----------------------------------------- From stanly@crunch.unm.edu Fri May 7 11:31:29 1993 Received: from crunch.unm.edu by cs.rice.edu (AA04665); Fri, 7 May 93 11:31:29 CDT Received: by crunch.unm.edu (4.1/3.1) id ; Fri, 7 May 93 10:31:25 MDT Date: Fri, 7 May 93 10:31:25 MDT From: stanly@crunch.unm.edu (Stanly Steinberg) Message-Id: <9305071631.AA02172@crunch.unm.edu> To: hpff-comments@cs.rice.edu Subject: HPF programming problem.. To: HPF Comments hpff-comments@cs.rice.edu Fr: Stanly Steinberg, stanly@math.unm.edu Re: How is this done? Da: 5/7/93 I have just read over lightly the HPF Language Specification draft dated No. 6, 1992, V 0.4 I have a problem where I am given six array and need to compute 23 new arrays. the computations, in the simplest case all look like B1(i,j,k) = (Ax(i+1,j,k)+Ay(i,j+1,k))/2 The + signs are replaced by - signs in all combinations and all combinations of incremented indices are used, and x,y range over 1-6 with x!= y. It appears that such a computation, written in F90, will run optimally slow on all parallel machines. An obvious strategy is to break each array into the same number of blocks as there are processor and then allocate the related blocks to the same processor. In addition, each processor needs to have the first layer of points of its neighboring blocks on it. Thus there is some modest data duplication, but now the arithmetic can be done with out communication. However, simple array adds may muck up the arithmetic. Can this be done in HPF in some elementary way? From J.I.CLEVELAND.II@larc.nasa.gov Thu May 27 14:23:12 1993 Received: from express.larc.nasa.gov by titan.cs.rice.edu (AA06268); Thu, 27 May 93 14:23:12 CDT Received: from localhost by express.larc.nasa.gov with SMTP id BA24596 (SMTP/Lite-1.15) for ; Thu, 27 May 93 15:23:01 -0400 Date: Thu, 27 May 1993 15:17:06 -0400 (EDT) From: JEFF I CLEVELAND II Subject: Entire High Performance Fortran Language Specification To: hpff-comments@cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Would you please consider making a Postscript copy with a slightly bolder font? I find the typeface a little difficult to read. Thank you for your consideration. Jeff Cleveland II From @prg.ox.ac.uk:Paul.Wesson@na.oxford.ac.uk Wed Jun 9 09:50:51 1993 Received: from sun2.nsfnet-relay.ac.uk by cs.rice.edu (AA07972); Wed, 9 Jun 93 09:50:51 CDT Via: uk.ac.oxford.prg; Wed, 9 Jun 1993 15:30:24 +0100 Received: from comlab.ox.ac.uk (client29.comlab) by prg.oxford.ac.uk id AA21966; Wed, 9 Jun 93 15:29:59 +0100 Received: by comlab.ox.ac.uk (4.1/comlab3.1) id AA26451; Wed, 9 Jun 93 15:30:25 BST Date: Wed, 9 Jun 93 15:30:25 BST From: Paul.Wesson@na.ox.ac.uk Message-Id: <9306091430.AA26451@client29.comlab.ox.ac.uk> To: hpff-comments@cs.rice.edu Subject: HPFF Question. Dear Sir/Madam, 9th June '93 >>> Ref: DISTRIBUTION DIRECTIVES <<< I'm involved in developing a parallel program for electromagnetic calculations on unstructured three dimensional meshes. The basic sequential code is running and I'm working on porting the code to a "general distributed memory" parallel machine. To load balance the calculations the mesh is allocated over the available processes using standard partitioning algorithms, in my case, Recursive Spectral Bisection. Anyway I'm at the position where I know where to allocate my unknowns. Using this information a "compiler" should be able to generate the correct message routines. Rather than coding this myself I wondered if HPF would be a practical option. My rough impression of HPF is that it's similar to using "tiles" on the KSR1 where arrays are allocated in blocks, or cyclically, over the available processors. This is similar to the !HPF$ DISTRIBUTE directive. This is ideal if you're working on regular grids but no for unstructures meshes. Well my main question is that can the DISTRIBUTE directive be used to allocate the array A(10), say over the processes so that Process 1 gets components 2,5,6,7 Process 2 1,3,4,8,9,10 using HPF directives? If not, will HPFF version 2.0 do it? Or have I overlooked another directive. Any help would be welcomed. Paul. ---------------------------------------------------------------- Dr PJ Wesson Oxford Parallel Programme Oxford University Computing Laboratory 11 Keble Road. Oxford. OX1 3QD +44 865 73839 (fax) ---------------------------------------------------------------- From oper@icavax.ica.uni-stuttgart.d400.de Thu Jul 15 10:52:50 1993 Received: from noc.BelWue.DE by titan.cs.rice.edu (AA25682); Thu, 15 Jul 93 10:52:50 CDT Received: from mailway.noc.belwue.de (noc.BelWue.DE) by noc.BelWue.DE with SMTP id AA27724 (5.65c/BelWue-M2.04 for ); Thu, 15 Jul 1993 17:52:43 +0200 X400-Received: by /PRMD=belwue/ADMD=_/C=de/; Relayed; 15 Jul 93 17:52:42+0100 X400-Received: by /PRMD=uni-stuttgart/ADMD=dbp/C=de/; Relayed; 15 Jul 93 17:51:05+0800 Forwarded-From: oper Date: 15 Jul 93 17:51:05+0800 From: Mail Delivery Subsystem Message-Id: <199307151509.AA19691@noc.BelWue.DE> To: oper@icavax.ica.uni-stuttgart.d400.de Cc: mailer-errors@noc.belwue.de Subject: Returned mail: Host unknown ----- Transcript of session follows ----- 550 cs.rice.edu.rus.uni-stuttgart.de (TCP)... 550 Host unknown 554 ... 550 Host unknown (Authoritative answer from name server) ----- Unsent message follows ----- Received: from mailway.noc.belwue.de (noc.BelWue.DE) by noc.BelWue.DE with SMTP id AA19687 (5.65c/BelWue-M2.04 for ); Thu, 15 Jul 1993 17:09:01 +0200 X400-Received: by /PRMD=belwue/ADMD=_/C=de/; Relayed; 15 Jul 93 17:09:00+0100 X400-Received: by /PRMD=uni-stuttgart/ADMD=dbp/C=de/; Relayed; 15 Jul 93 17:07:26+0800 Date: 15 Jul 93 17:07:26+0800 From: oper To: hpff-comments@cs.rice.edu.rus.uni-stuttgart.de Subject: HighPerformanceFortran Dokument1 file hpf-v10.tar.Z nicht gefunden Message-Id: <11*oper@icavax.ica.uni-stuttgart.d400.de> Problem : BI.5.1993 im rusinfo(129.69.1.12) als gepackter TEX (.tar.Z) file unter /info/parallelrechner/HPF als hpf-v10.tar.Z vorliegen. Unter dieser Direktory liegen diverse postscript files aber kein TEX (.tar.Z) file vor, die aufgrund ihrer besonderen laenge Probleme beim ausdrucken bereiten. Frage: Wurde der hpf-v10.tar.Z file removed oder existiert er noch und wenn ja in welcher directory? Vielen Dank Joachim Koch koch@icamv5.uni-stuttgart.de From oper@icavax.ica.uni-stuttgart.d400.de Thu Jul 15 11:22:20 1993 Received: from noc.BelWue.DE by titan.cs.rice.edu (AA26427); Thu, 15 Jul 93 11:22:20 CDT Received: from mailway.noc.belwue.de (noc.BelWue.DE) by noc.BelWue.DE with SMTP id AA00325 (5.65c/BelWue-M2.04 for ); Thu, 15 Jul 1993 18:22:18 +0200 X400-Received: by /PRMD=belwue/ADMD=_/C=de/; Relayed; 15 Jul 93 18:22:17+0100 X400-Received: by /PRMD=uni-stuttgart/ADMD=dbp/C=de/; Relayed; 15 Jul 93 18:20:27+0800 Date: 15 Jul 93 18:20:27+0800 From: oper To: hpff-comments@cs.rice.edu Subject: HighPerformanceFortran file hpf-v10.tar.Z not found Importance: Normal Sensitivity: Personal Message-Id: <14*oper@icavax.ica.uni-stuttgart.d400.de> Problem: Das im BI.5.1993 vorgestellte Dokument1 zu HPF sollte im rusinfo (129.69.1.12) unter /info/prallelrechner/HPF als gepackter TEX (.tar.Z) file vorliegen. unter der genannten directory waren aber nur div. ps files vorhanden, deren hohe Groesse grosse Probleme beim Ausdrucken bereitete (es wurde rudimentaer gedruckt). Frage: Wurde der file hpf-v10.tar.Z removed oder existiert er noch ? Wenn ja in welcher directory und unter welchem Pfad ? Vielen Dank Joachim Koch koch@icamv6.uni-stuttgart oper@icavax.uni-stuttgart From oper@icavax.ica.uni-stuttgart.d400.de Thu Jul 15 11:23:23 1993 Received: from noc.BelWue.DE by titan.cs.rice.edu (AA26527); Thu, 15 Jul 93 11:23:23 CDT Received: from mailway.noc.belwue.de (noc.BelWue.DE) by noc.BelWue.DE with SMTP id AA00390 (5.65c/BelWue-M2.04 for ); Thu, 15 Jul 1993 18:23:21 +0200 X400-Received: by /PRMD=belwue/ADMD=_/C=de/; Relayed; 15 Jul 93 18:23:21+0100 X400-Received: by /PRMD=uni-stuttgart/ADMD=dbp/C=de/; Relayed; 15 Jul 93 18:21:44+0800 Date: 15 Jul 93 18:21:44+0800 From: oper To: hpff-comments@cs.rice.edu Subject: HighPerformanceFortran file hpf-v10.tar.Z not found Importance: Normal Sensitivity: Personal Message-Id: <14*oper@icavax.ica.uni-stuttgart.d400.de> Problem: Das im BI.5.1993 vorgestellte Dokument1 zu HPF sollte im rusinfo (129.69.1.12) unter /info/prallelrechner/HPF als gepackter TEX (.tar.Z) file vorliegen. unter der genannten directory waren aber nur div. ps files vorhanden, deren hohe Groesse grosse Probleme beim Ausdrucken bereitete (es wurde rudimentaer gedruckt). Frage: Wurde der file hpf-v10.tar.Z removed oder existiert er noch ? Wenn ja in welcher directory und unter welchem Pfad ? Vielen Dank Joachim Koch koch@icamv6.uni-stuttgart oper@icavax.uni-stuttgart From rro@debussy.cs.colostate.edu Wed Aug 4 11:25:23 1993 Received: from yuma.ACNS.ColoState.EDU by titan.cs.rice.edu (AA17988); Wed, 4 Aug 93 11:25:23 CDT Received: from debussy.cs.colostate.edu by yuma.ACNS.ColoState.EDU (AIX 3.2/UCB 5.64/4.03) id AA71728; Wed, 4 Aug 1993 10:24:33 -0600 Received: by debussy.CS.ColoState.EDU (5.57/Ultrix3.0-C) id AA17552; Wed, 4 Aug 93 10:24:32 -0600 From: rro@cs.colostate.edu (Rod Oldehoeft) Message-Id: <9308041624.AA17552@debussy.CS.ColoState.EDU> Subject: Latest version? To: hpff-comments@cs.rice.edu Date: Wed, 4 Aug 1993 10:24:31 -0600 (MDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 883 Hello, I have a draft HPF language specification dated January 25, 1993 and labeled Version 1.0 DRAFT. Can you tell me if there is a newer version available? I got this draft via anonymous ftp, but do not recall from where, so if there is a newer version I'd appreciate a pointer. Thanks. -- |--------------------------------------------------------------| | Rod Oldehoeft Email: rro@cs.colostate.edu | | Computer Science Department Voice: 303/491-5792 | | Colorado State University Fax: 303/491-6639 | | Fort Collins, CO 80523 | |--------------------------------------------------------------| | It ain't what people don't know that hurts, , it's the | | things they know that ain't so. ---Artemus Ward | |--------------------------------------------------------------| From adamm@nasoftwr.demon.co.uk Wed Nov 10 15:02:33 1993 Received: from post.demon.co.uk by cs.rice.edu (AA02920); Wed, 10 Nov 93 15:02:33 CST Received: from nasoftwr.demon.co.uk by post.demon.co.uk id aa05983; 10 Nov 93 17:15 GMT Received: from nasoftwr.demon.co.uk (porsche) by nasoftwr.demon.co.uk id AA00989; Wed, 10 Nov 93 15:56:17 GMT Received: by nasoftwr.demon.co.uk id AA08116; Wed, 10 Nov 93 15:56:19 GMT Date: Wed, 10 Nov 93 15:56:19 GMT From: Adam Marshall Message-Id: <9311101556.AA08116@nasoftwr.demon.co.uk> To: hpff-comments@cs.rice.edu Subject: INHERIT attribute Good sirs, I'm afraid I have problems with section 3.10 of Version 1.0 Draft 2: There is syntactic goof - P48 lines 3-4 "If a dummy argument has the INHERIT attribute and no explicit ALIGN or DISTRIBUTE action.." If a dummy argument has the INHERIT attribute it is *forbidden* to have an ALIGN action. (Page 44 lines 22-23). Any mention of ALIGN should be removed from this sentence. Adam Marshall (NA Software, Liverpool. UK) From adamm@nasoftwr.demon.co.uk Wed Nov 10 15:04:25 1993 Received: from post.demon.co.uk by cs.rice.edu (AA02984); Wed, 10 Nov 93 15:04:25 CST Received: from nasoftwr.demon.co.uk by post.demon.co.uk id aa06141; 10 Nov 93 17:16 GMT Received: from nasoftwr.demon.co.uk (porsche) by nasoftwr.demon.co.uk id AA00992; Wed, 10 Nov 93 15:58:49 GMT Received: by nasoftwr.demon.co.uk id AA08143; Wed, 10 Nov 93 15:58:51 GMT Date: Wed, 10 Nov 93 15:58:51 GMT From: Adam Marshall Message-Id: <9311101558.AA08143@nasoftwr.demon.co.uk> To: hpff-comments@cs.rice.edu Subject: Subprogram Interfaces I have a further problem with section 3.10 of Version 1.0 Draft 2: There is another syntactic goof - P49 line 43 "One may omit either the dist-format-clause or the dist-target-clause" The problem is dist-target-clause is never defined - I think you mean dist-onto-clause. Adam Marshall (NA Software, Liverpool. UK)