From owner-hpff-interpret Fri Jun 7 04:40:05 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id EAA15877 for hpff-interpret-out; Fri, 7 Jun 1996 04:40:05 -0500 (CDT) Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id EAA15872 for ; Fri, 7 Jun 1996 04:39:59 -0500 (CDT) Received: from chad2-13.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Fri, 7 Jun 1996 10:39:53 +0100 From: "Dr A.C. Marshall" Message-Id: <199606070939.KAA21618@chad2-13.liv.ac.uk> Subject: hpff-interpret: Local code vs. global code To: hpff-interpret@cs.rice.edu (HPFF) Date: Fri, 7 Jun 1996 10:39:50 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Dear all, I have been having trouble with an example from the HPF Handbook P225/6 and Figures 8.1 and 8.2. There is an example "Munch_Columns" which has been written as an HPF_LOCAL EXTRINSIC: EXTRINSIC (HPF_LOCAL) SUBROUTINE MUNCHCOLUMNS(A) REAL A(:,:) INTEGER i,j !HPF$ INDEPENDENT, NEW(I) DO j=1,ubound(A,2) i = 1 DO WHILE (i <= ubound(A,1)) IF (A(i,j) /= 0.0) THEN A(1:i-1,j) = A(i,j) EXIT END IF i = i + 1 END DO END DO END Assuming that A is DISTRIBUTEd (*, BLOCK) (which it is) then each instance of "Munch_Columns" is free to work on its own set of columns. There is NO synchronisation within the EXTRINSIC and, if appropriate, each "j" iteration can be executed concurrently. The code given in Fig 8.2 (the GLOBAL HPF code) is quite clearly incorrect in a number of areas (incorrect MASK specification and wrong number of dimensions given in references to A [whoops]). I claim, however, that the following could be used as GLOBAL code: EXTRINSIC (HPF) SUBROUTINE MUNCHCOLUMNS(A) REAL A(:,:) INTEGER i,j !HPF$ DISTRIBUTE A(*,BLOCK) !HPF$ INDEPENDENT, NEW(I) DO j=1,ubound(A,2) i = 1 DO WHILE (i <= ubound(A,1)) IF (A(i,j) /= 0.0) THEN A(1:i-1,j) = A(i,j) EXIT END IF i = i + 1 END DO END DO END As far as I can tell this code should work correctly. If this is true then each processor will be able to work on its own set of columns and accoring to the INDEPENDENT directive, if appropriate, each "j" iteration can be executed concurrently. The thing which confuses me is the paragraph half way down page 226: "While MUNCHCOLUMNS could be expressed as global HPF code the local version might be faster because it exploits the idea that only a prefix of each column needs to be examined and processed. Each processor may take a different time to process its first column; the local code clearly indicates that the processes synchronise only after processing all columns not after processing each column." Basically, I do not understand why the global version needs to synchronise after processing each column. According to the INDEPENDENT directive, the "j" iterations (which select the column to work on) do not interfere with each other, so they can be performed without synchronisation. Clearly I am missing something here! Could some kind soul please explain why the local version is likely to be faster than the global version. I appreciate that one answer could be that INDEPENDENT is generally parsed and then ignored whereas a call to a local extrinsic is guaranteed to exploit parallelism, however, does not seem to be the reason cited in the handbook. If indeed the MUNCHCOLUMNS example does NOT actually demonstrate how local code can be used to avoid unecessary synchronisation then could somebody cite an example that does? Adam Marshall (in a state of confusion) -- Dr AC Marshall | Computing Services Department, | University of Liverpool, | WATCH THIS SPACE PO Box 147. L69 3BX | email: adamm@liv.ac.uk | Tel: +44-151-794 3722 | Fax: +44-151-794 3759 | Take a look at: HPC Info: http://www.liv.ac.uk/HPC/HPCpage.html Adam Info: http://www.liv.ac.uk/~adamm/HomePage.html --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Jun 10 13:03:49 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA07651 for hpff-interpret-out; Mon, 10 Jun 1996 13:03:49 -0500 (CDT) Received: from pacific.pgroup.com (pacific.pgroup.com [192.124.124.8]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id NAA07644 for ; Mon, 10 Jun 1996 13:03:44 -0500 (CDT) Received: from columbia.pgroup.com (columbia [192.124.124.2]) by pacific.pgroup.com (8.7.5/8.6.11) with ESMTP id LAA10969 for ; Mon, 10 Jun 1996 11:03:44 -0700 (PDT) Received: (from lfm@localhost) by columbia.pgroup.com (8.7.5/8.7.2) id LAA05588 for hpff-interpret@cs.rice.edu; Mon, 10 Jun 1996 11:03:44 -0700 (PDT) Message-Id: <199606101803.LAA05588@columbia.pgroup.com> Subject: hpff-interpret: MODULE, USE only, and !hpf$ template To: hpff-interpret@cs.rice.edu Date: Mon, 10 Jun 1996 11:03:43 -0700 (PDT) From: "Larry Meadows" X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Is this legal: module M !hpf$ template T(100,100) !hpf$ distribute T(block,block) end module use M, only:: T end T is not a first-class object. If M is USEd, then I guess T is available. But can T be named in a F90 statement? lfm --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Jun 10 13:59:22 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA10914 for hpff-interpret-out; Mon, 10 Jun 1996 13:59:22 -0500 (CDT) Received: from [128.42.1.213] (morpheus.cs.rice.edu [128.42.1.213]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id NAA10905; Mon, 10 Jun 1996 13:59:16 -0500 (CDT) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jun 1996 14:00:53 -0600 To: "Larry Meadows" From: chk@cs.rice.edu (Chuck Koelbel) Subject: Re: hpff-interpret: MODULE, USE only, and !hpf$ template Cc: hpff-interpret@cs.rice.edu Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- At 11:03 06/10/96, Larry Meadows wrote: > >Is this legal: > > >module M >!hpf$ template T(100,100) >!hpf$ distribute T(block,block) >end module > >use M, only:: T >end > > >T is not a first-class object. If M is USEd, then I guess T is available. >But can T be named in a F90 statement? > >lfm I would say "no". In general, if something is not a first-class object, then it cannot be used in an Fortran 90 statement. (If it were, then the program would violate the "if you ignore the directives then it's legal F90" principle.) Chuck --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Jun 10 14:14:37 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id OAA11446 for hpff-interpret-out; Mon, 10 Jun 1996 14:14:37 -0500 (CDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id OAA11431 for ; Mon, 10 Jun 1996 14:14:30 -0500 (CDT) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0567; Mon, 10 Jun 96 15:14:17 EDT Received: by TOROLAB (XAGENTA 4.0) id 0487; Mon, 10 Jun 1996 15:16:59 -0400 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA26338; Mon, 10 Jun 1996 15:13:49 -0400 From: (Henry Zongaro) Message-Id: <9606101913.AA26338@twinpeaks.torolab.ibm.com> Subject: Re: hpff-interpret: MODULE, USE only, and !hpf$ template To: lfm@pgroup.com (Larry Meadows) Date: Mon, 10 Jun 1996 15:13:47 -0400 (EDT) Cc: hpff-interpret@cs.rice.edu In-Reply-To: <199606101803.LAA05588@columbia.pgroup.com> from "Larry Meadows" at Jun 10, 96 11:03:43 am X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Hi Larry, > Is this legal: > > > module M > !hpf$ template T(100,100) > !hpf$ distribute T(block,block) > end module > > use M, only:: T > end > > > T is not a first-class object. If M is USEd, then I guess T is available. > But can T be named in a F90 statement? This same question was answered at the October, 1994 meeting (CCI 9.2). The response was that the name of a template (or processors arrangement) cannot be specified in the of a USE statement. The rationale was that a valid HPF program should also be a valid Fortran 90 program (ignoring such things as FORALL, PURE, EXTRINSIC and other language extensions). If we treat the HPF directives in the above program as comments, it is no longer a valid Fortran 90 program. Thanks, Henry --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Jun 10 14:30:05 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id OAA12163 for hpff-interpret-out; Mon, 10 Jun 1996 14:30:05 -0500 (CDT) Received: from aga.npac.syr.edu (aga.npac.syr.edu [128.230.117.22]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id OAA12155; Mon, 10 Jun 1996 14:29:57 -0500 (CDT) Received: from localhost (haupt@localhost) by aga.npac.syr.edu (940816.SGI.8.6.9/8.6.6) with SMTP id PAA21509; Mon, 10 Jun 1996 15:29:36 -0400 Message-Id: <199606101929.PAA21509@aga.npac.syr.edu> X-Authentication-Warning: aga.npac.syr.edu: Host localhost didn't use HELO protocol To: chk@cs.rice.edu (Chuck Koelbel) cc: "Larry Meadows" , hpff-interpret@cs.rice.edu, haupt@aga.npac.syr.edu Subject: Re: hpff-interpret: MODULE, USE only, and !hpf$ template In-reply-to: Your message of "Mon, 10 Jun 1996 14:00:53 MDT." Date: Mon, 10 Jun 1996 15:29:35 -0400 From: Tomasz Haupt Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- >>Is this legal: >> >> >>module M >>!hpf$ template T(100,100) >>!hpf$ distribute T(block,block) >>end module >> >>use M, only:: T >>end >> >> >>T is not a first-class object. If M is USEd, then I guess T is av >ailable. >>But can T be named in a F90 statement? >> >>lfm > >I would say "no". > >In general, if something is not a first-class object, then it cann >ot be >used in an Fortran 90 statement. (If it were, then the program wo >uld >violate the "if you ignore the directives then it's legal F90" pri >nciple.) > > Chuck > As an HPF user I find it a little confusing. I do use modules similar to Larry's module M, without "only:: T" however. Chuck's argument is OK. Nevertheless T can appear only in a !hpf$ directive, i.e., f90 comment line, do it does no harm. This way you make life of a programmer easier. It saves necessity to write yet another perl script to maintain consistency of my HPF codes. Tom --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jun 11 07:50:42 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id HAA08876 for hpff-interpret-out; Tue, 11 Jun 1996 07:50:42 -0500 (CDT) Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.108]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id HAA08871; Tue, 11 Jun 1996 07:50:32 -0500 (CDT) Received: from post.demon.co.uk ([158.152.1.72]) by relay-4.mail.demon.net id bs22307; 11 Jun 96 12:45 GMT Received: from nasoftwr.demon.co.uk ([158.152.18.126]) by relay-3.mail.demon.net id aa17342; 11 Jun 96 9:34 +0100 Received: from ferrari.nasoftware by nasoftwr.demon.co.uk id JAA09669; Tue, 11 Jun 1996 09:12:01 +0100 From: Junxian Liu Received: from porsche.nasoftware by ferrari.nasoftware id AA26298; Tue, 11 Jun 96 09:10:55 BST Local-From: jliu@ferrari (Junxian Liu) Message-Id: <9606110810.AA26298@ferrari.nasoftware> Subject: Re: hpff-interpret: MODULE, USE only, and !hpf$ template To: Chuck Koelbel Date: Tue, 11 Jun 1996 09:10:53 +0100 (BST) Cc: hpff-interpret@cs.rice.edu In-Reply-To: from "Chuck Koelbel" at Jun 10, 96 02:00:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > At 11:03 06/10/96, Larry Meadows wrote: > > > >Is this legal: > > > > > >module M > >!hpf$ template T(100,100) > >!hpf$ distribute T(block,block) > >end module > > > >use M, only:: T > >end > > > > > >T is not a first-class object. If M is USEd, then I guess T is available. > >But can T be named in a F90 statement? > > > >lfm > > I would say "no". > > In general, if something is not a first-class object, then it cannot be > used in an Fortran 90 statement. (If it were, then the program would > violate the "if you ignore the directives then it's legal F90" principle.) > > Chuck > Just mention a few of violations of the "if you ignore the directives then it's legal F90" principle: FORALL, EXTRINSIC, PURE If any of these is used, the program is no longer legal fortran 90. For the original question, I would say it is legal HPF (since a HPF program is not legal F90 anyway in many cases). ----- Dr Junxian Liu email: jliu@nasoftwr.demon.co.uk NA Software Ltd jliu@nasoftware.co.uk Roscoe House 62 Roscoe Street telephone: +44 151 709 4738 Liverpool L1 9DW fax: +44 151 709 5645 --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jun 11 08:19:13 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id IAA09307 for hpff-interpret-out; Tue, 11 Jun 1996 08:19:13 -0500 (CDT) Received: from daedalus.epcc.ed.ac.uk (root@daedalus.epcc.ed.ac.uk [129.215.56.21]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id IAA09301 for ; Tue, 11 Jun 1996 08:19:08 -0500 (CDT) Received: from subnode.epcc.ed.ac.uk (harvey@tequila.epcc.ed.ac.uk [129.215.94.7]) by daedalus.epcc.ed.ac.uk (8.6.13/8.6.12) with SMTP id OAA20128; Tue, 11 Jun 1996 14:18:44 +0100 Date: Tue, 11 Jun 96 14:18:43 BST Message-Id: <5281.9606111318@subnode.epcc.ed.ac.uk> To: jliu@nasoftwr.demon.co.uk Subject: Re: hpff-interpret: MODULE, USE only, and !hpf$ template Cc: hpff-interpret@cs.rice.edu, hjr@think.com From: Harvey Richardson Organisation: Thinking Machines Corporation Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > > I would say "no". > > > > In general, if something is not a first-class object, then it cannot be > > used in an Fortran 90 statement. (If it were, then the program would > > violate the "if you ignore the directives then it's legal F90" principle.) > > > > Chuck > > > > Just mention a few of violations of the "if you ignore the directives > then it's legal F90" principle: > > FORALL, EXTRINSIC, PURE > > If any of these is used, the program is no longer legal fortran 90. > > For the original question, I would say it is legal HPF (since a HPF > program is not legal F90 anyway in many cases). > > ----- > Dr Junxian Liu email: jliu@nasoftwr.demon.co.uk > NA Software Ltd jliu@nasoftware.co.uk You have a strange definition of "directive". With F95 coming along this seems a bit academic anyway. Maybe the solution is: HPF$ USE M, only :: T Harvey --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jun 11 08:34:44 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id IAA09556 for hpff-interpret-out; Tue, 11 Jun 1996 08:34:44 -0500 (CDT) Received: from aga.npac.syr.edu (aga.npac.syr.edu [128.230.117.22]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id IAA09550 for ; Tue, 11 Jun 1996 08:34:41 -0500 (CDT) Received: from localhost (haupt@localhost) by aga.npac.syr.edu (940816.SGI.8.6.9/8.6.6) with SMTP id JAA23468; Tue, 11 Jun 1996 09:32:09 -0400 Message-Id: <199606111332.JAA23468@aga.npac.syr.edu> X-Authentication-Warning: aga.npac.syr.edu: Host localhost didn't use HELO protocol To: Harvey Richardson cc: jliu@nasoftwr.demon.co.uk, hpff-interpret@cs.rice.edu, haupt@aga.npac.syr.edu Subject: Re: hpff-interpret: MODULE, USE only, and !hpf$ template In-reply-to: Your message of "Tue, 11 Jun 1996 14:18:43 -0000." <5281.9606111318@subnode.epcc.ed.ac.uk> Date: Tue, 11 Jun 1996 09:32:09 -0400 From: Tomasz Haupt Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > >Maybe the solution is: > >HPF$ USE M, only :: T > >Harvey It looks quite weird, but maybe it is a solution. "T" is an HPF object, and it can appear in the code only in the directives anyway. So it is consistent at this respect. Tom --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jun 11 09:47:57 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA11648 for hpff-interpret-out; Tue, 11 Jun 1996 09:47:57 -0500 (CDT) Received: from [128.42.1.213] (morpheus.cs.rice.edu [128.42.1.213]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id JAA11634; Tue, 11 Jun 1996 09:47:49 -0500 (CDT) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Jun 1996 09:49:27 -0600 To: Junxian Liu From: chk@cs.rice.edu (Chuck Koelbel) Subject: Re: hpff-interpret: MODULE, USE only, and !hpf$ template Cc: Chuck Koelbel , hpff-interpret@cs.rice.edu Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- At 09:10 06/11/96, Junxian Liu wrote: > >Just mention a few of violations of the "if you ignore the directives >then it's legal F90" principle: > > FORALL, EXTRINSIC, PURE > >If any of these is used, the program is no longer legal fortran 90. > >For the original question, I would say it is legal HPF (since a HPF >program is not legal F90 anyway in many cases). > >----- >Dr Junxian Liu email: jliu@nasoftwr.demon.co.uk >NA Software Ltd jliu@nasoftware.co.uk Note that FORALL, EXTRINSIC, and PURE are first-class language constructs, not directives. Similarly for calls to the HPF library. It was a design principle that anything that changed the semantics of the program had to be a "real" part of the language, not a directive (i.e. a statement/declaration/expression, not a structured comment). Your point that there are things in HPF that are not F90 is well-taken. But that does not mean that we should add new differences between the languages. Chuck --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jun 11 10:04:50 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA12439 for hpff-interpret-out; Tue, 11 Jun 1996 10:04:50 -0500 (CDT) Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id KAA12409; Tue, 11 Jun 1996 10:04:43 -0500 (CDT) Received: from chad2-13.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Tue, 11 Jun 1996 16:04:18 +0100 From: "Dr A.C. Marshall" Message-Id: <199606111504.QAA19056@chad2-13.liv.ac.uk> Subject: hpff-interpret: Changing semantics To: chk@cs.rice.edu (Chuck Koelbel) Date: Tue, 11 Jun 1996 16:04:09 +0100 (BST) Cc: hpff-interpret@cs.rice.edu (HPFF) In-Reply-To: from "Chuck Koelbel" at Jun 11, 96 09:49:27 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- In the last mail Chuck Koelbel said: | |....... It was a design |principle that anything that changed the semantics of the program had to be |a "real" part of the language, not a directive (i.e. a |statement/declaration/expression, not a structured comment). | Ah but adding an INDEPENDENT directive may change the semantics of the program if the loop index variable is used before reassignment. The loop variable in the HPF version will have a different value to the F90 version (either this or the value will be undefined). Did anybody have any ideas on my EXTRINSIC local routine question of last week. This was a question based on a paragraph from the HPF Handbook. Adam Marshall -- Dr AC Marshall | Computing Services Department, | University of Liverpool, | WATCH THIS SPACE PO Box 147. L69 3BX | email: adamm@liv.ac.uk | Tel: +44-151-794 3722 | Fax: +44-151-794 3759 | Take a look at: HPC Info: http://www.liv.ac.uk/HPC/HPCpage.html Adam Info: http://www.liv.ac.uk/~adamm/HomePage.html --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jun 11 11:02:32 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id LAA14990 for hpff-interpret-out; Tue, 11 Jun 1996 11:02:32 -0500 (CDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id LAA14985 for ; Tue, 11 Jun 1996 11:02:29 -0500 (CDT) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3392; Tue, 11 Jun 96 12:02:15 EDT Received: by TOROLAB (XAGENTA 4.0) id 1011; Tue, 11 Jun 1996 12:04:55 -0400 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA22749; Tue, 11 Jun 1996 12:02:16 -0400 From: (Henry Zongaro) Message-Id: <9606111602.AA22749@twinpeaks.torolab.ibm.com> Subject: Re: hpff-interpret: Changing semantics To: adamm@liverpool.ac.uk (Dr A.C. Marshall) Date: Tue, 11 Jun 1996 12:02:14 -0400 (EDT) Cc: chk@cs.rice.edu, hpff-interpret@cs.rice.edu In-Reply-To: <199606111504.QAA19056@chad2-13.liv.ac.uk> from "Dr A.C. Marshall" at Jun 11, 96 04:04:09 pm X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- A.C. Marshall wrote: > In the last mail Chuck Koelbel said: > | > |....... It was a design > |principle that anything that changed the semantics of the program had to be > |a "real" part of the language, not a directive (i.e. a > |statement/declaration/expression, not a structured comment). > | > > Ah but adding an INDEPENDENT directive may change the semantics of the > program if the loop index variable is used before reassignment. The loop > variable in the HPF version will have a different value to the F90 version > (either this or the value will be undefined). I have to disagree with this - INDEPENDENT directive does not absolve a compiler from having to make sure that the loop index variable has the correct final value. CCI #40 inquires about the meaning of the following: !HPF$ INDEPENDENT, NEW(I) DO I = 1, 10 END DO The response indicates that in this case, the value of I is undefined after the loop. But if I is not specified in the NEW clause, nothing in HPF specifies that the value of I is anything other than 11. Thanks, Henry --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Wed Jun 12 09:14:05 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA16365 for hpff-interpret-out; Wed, 12 Jun 1996 09:14:05 -0500 (CDT) Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id JAA16360 for ; Wed, 12 Jun 1996 09:14:00 -0500 (CDT) Received: from chad2-13.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Wed, 12 Jun 1996 15:13:19 +0100 From: "Dr A.C. Marshall" Message-Id: <199606121413.PAA15954@chad2-13.liv.ac.uk> Subject: Re: hpff-interpret: Changing semantics To: harvey@epcc.ed.ac.uk (Harvey Richardson) Date: Wed, 12 Jun 1996 15:13:08 +0100 (BST) Cc: hpff-interpret@cs.rice.edu (HPFF) In-Reply-To: <5718.9606120849@subnode.epcc.ed.ac.uk> from "Harvey Richardson" at Jun 12, 96 09:49:02 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- In the last mail Harvey Richardson said: | |> Ah but adding an INDEPENDENT directive may change the semantics of the |> program if the loop index variable is used before reassignment. The loop |> variable in the HPF version will have a different value to the F90 version |> (either this or the value will be undefined). |> | |This is wrong :-) | |The code has exactly the same interpretation and the final value |must be correct | |so | |HPF$ INDEPENDENT | DO i=1,n | a(i) = i | END DO | |Sets i to max(1,n+1) after the loop. | I actually meant INDEPENDENT, NEW directives. |HPF$ INDEPENDENT,NEW(j) | DO i=1,n | DO j = 1,n | b(i,j) = j*i | END DO | a(i) = i | END DO Is the compiler also forced to give j the value of max(1,n+1)? Adam -- Dr AC Marshall | Computing Services Department, | University of Liverpool, | WATCH THIS SPACE PO Box 147. L69 3BX | email: adamm@liv.ac.uk | Tel: +44-151-794 3722 | Fax: +44-151-794 3759 | Take a look at: HPC Info: http://www.liv.ac.uk/HPC/HPCpage.html Adam Info: http://www.liv.ac.uk/~adamm/HomePage.html --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Wed Jun 26 09:01:36 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA29464 for hpff-interpret-out; Wed, 26 Jun 1996 09:01:36 -0500 (CDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id JAA29457 for ; Wed, 26 Jun 1996 09:01:32 -0500 (CDT) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9997; Wed, 26 Jun 96 10:01:13 EDT Received: by TOROLAB (XAGENTA 4.0) id 1831; Wed, 26 Jun 1996 09:58:47 -0400 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA27278; Wed, 26 Jun 1996 10:01:17 -0400 From: (Henry Zongaro) Message-Id: <9606261401.AA27278@twinpeaks.torolab.ibm.com> Subject: hpff-interpret: No mapping directives in explicit interface? To: hpff-interpret@cs.rice.edu (HPPF Interpretations) Date: Wed, 26 Jun 1996 10:01:13 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Hello, According to Section 3.10 of the HPF Language Spec., If there is an explicit interface for the called subprogram and that interface contains mapping directives (whether prescriptive or descriptive) for the dummy argument in question, the actual argument will be remapped if necessary to conform to the directives in the explicit interface. However, it does not state what should happen if there is an explicit interface that does not contain explicit mapping directives. I always took it to mean that the mapping would be determined by the called procedure, just as it would be for procedures with implicit interfaces, rather than happening on the calling side. For example, my understanding is that the calls to sub1 and sub2 would be permitted, but not the call to sub3, just as the calls would be permitted if sub1, sub2 and sub3 had implicit interfaces in prog. program prog interface subroutine sub1(a) integer :: a(:) end subroutine sub1 subroutine sub2(a) integer :: a(:) end subroutine sub2 subroutine sub3(a) integer :: a(:) end subroutine sub3 end interface integer :: a(100) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a(block) onto proc call sub1(a) call sub2(a) call sub3(a) end program prog subroutine sub1(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a(cyclic) onto proc end subroutine sub1 subroutine sub2(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a*(block) onto *proc end subroutine sub2 subroutine sub3(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a*(cyclic) onto *proc end subroutine sub3 Do others have a different understanding of how this operates? Thanks, Henry --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Wed Jun 26 11:06:17 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id LAA04093 for hpff-interpret-out; Wed, 26 Jun 1996 11:06:17 -0500 (CDT) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id LAA04086 for ; Wed, 26 Jun 1996 11:06:10 -0500 (CDT) Received: from Custard.Think.COM by mail.think.com; Wed, 26 Jun 96 11:44:37 -0400 From: Carol Munroe Received: by custard.think.com (4.1/Think-1.2) id AA07865; Wed, 26 Jun 96 12:06:02 EDT Date: Wed, 26 Jun 96 12:06:02 EDT Message-Id: <9606261606.AA07865@custard.think.com> To: zongaro@vnet.ibm.com Cc: hpff-interpret@cs.rice.edu In-Reply-To: Henry Zongaro's message of Wed, 26 Jun 1996 10:01:13 -0400 (EDT) <9606261401.AA27278@twinpeaks.torolab.ibm.com> Subject: hpff-interpret: No mapping directives in explicit interface? Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- From: (Henry Zongaro) Date: Wed, 26 Jun 1996 10:01:13 -0400 (EDT) --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Hello, According to Section 3.10 of the HPF Language Spec., If there is an explicit interface for the called subprogram and that interface contains mapping directives (whether prescriptive or descriptive) for the dummy argument in question, the actual argument will be remapped if necessary to conform to the directives in the explicit interface. However, it does not state what should happen if there is an explicit interface that does not contain explicit mapping directives. I always took it to mean that the mapping would be determined by the called procedure, just as it would be for procedures with implicit interfaces, rather than happening on the calling side. For example, my understanding is that the calls to sub1 and sub2 would be permitted, but not the call to sub3, just as the calls would be permitted if sub1, sub2 and sub3 had implicit interfaces in prog. Hi Henry, The following is my understanding of this example. I believe that the point of the explicit interface is to reconcile any possible discrepancy in mappings between the actual argument and the dummy argument, so that any remapping can always be done by the caller. The intention was also to remove the distinction between prescriptive and descriptive directives. It was not intended to prevent the callee from doing it, but by not removing the old syntactic distinction between prescriptive and descriptive directives, some ambiguity may remain. I believe that if a full interface is included, showing a discrepancy between the actual argument's mapping and an incompatible descriptive mapping for the dummy argument, the caller is apparently expected to make the remapping happen anyway. So with an explicit interface, the call to sub3 is correct. In particular, the lack of explicit mapping directives in the interface for sub1 means that there is no guarantee that the remapping will be done (since the caller doesn't see the need). The programmer is therefore taking a change by relying on the (no longer significant) "prescriptive" form of the directives in sub1. With sub2, the default mapping behavior of the compiler may or may not be nonsequential, block-distributed onto proc(number_of_processors()), so again there could be a failure. With sub3, again, the lack of an interface means that the caller does not remap as needed, so there will be a programmer's error. With an interface, the remapping would be done. --Carol program prog interface subroutine sub1(a) integer :: a(:) end subroutine sub1 subroutine sub2(a) integer :: a(:) end subroutine sub2 subroutine sub3(a) integer :: a(:) end subroutine sub3 end interface integer :: a(100) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a(block) onto proc call sub1(a) call sub2(a) call sub3(a) end program prog subroutine sub1(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a(cyclic) onto proc end subroutine sub1 subroutine sub2(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a*(block) onto *proc end subroutine sub2 subroutine sub3(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a*(cyclic) onto *proc end subroutine sub3 Do others have a different understanding of how this operates? Thanks, Henry --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Thu Jun 27 10:30:18 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA04316 for hpff-interpret-out; Thu, 27 Jun 1996 10:30:18 -0500 (CDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id KAA04309 for ; Thu, 27 Jun 1996 10:30:08 -0500 (CDT) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA20118; Thu, 27 Jun 1996 11:15:17 -0400 (EDT) Received: by mpsg.hpc.pko.dec.com; id AA12190; Thu, 27 Jun 1996 11:15:33 -0400 From: offner@hpc.pko.dec.com (Carl Offner) Received: by hardy.hpc.pko.dec.com; (5.65v3.2/1.1.8.2/01Nov94-0839AM) id AA19034; Thu, 27 Jun 1996 11:15:10 -0400 Date: Thu, 27 Jun 1996 11:15:10 -0400 Message-Id: <9606271515.AA19034@hardy.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: Re: No mapping directives in explicit interface? Cc: offner@hpc.pko.dec.com Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- On Henry's example: --------------------------------------------------------------------- program prog interface subroutine sub1(a) integer :: a(:) end subroutine sub1 subroutine sub2(a) integer :: a(:) end subroutine sub2 subroutine sub3(a) integer :: a(:) end subroutine sub3 end interface integer :: a(100) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a(block) onto proc call sub1(a) call sub2(a) call sub3(a) end program prog subroutine sub1(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a(cyclic) onto proc end subroutine sub1 subroutine sub2(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a*(block) onto *proc end subroutine sub2 subroutine sub3(a) integer :: a(:) !hpf$ processors proc(number_of_processors()) !hpf$ distribute a*(cyclic) onto *proc end subroutine sub3 --------------------------------------------------------------------- I would say that all three interfaces are non-conforming because the interfaces do not reflect the mappings. There are, to be sure, instances in which an interface would not be required -- sub2 is an example -- but if an interface is present, it should correctly reflect the mapping of all explicitly mapped arguments. Now I don't actually see that the HPF spec says precisely this. However, it was certainly the understanding behind the explicit interface proposal. After all, what is the point in requiring an explicit interface if the explicit interface does not have to describe the mappings? So maybe (unless some language lawyer can convince us all that this is already in the spec) we should add a sentence to this effect. Presumably this would be something like specifying that the mapping of a dummy argument is a "characteristic" of that argument, in the terminology of the Fortran standard. Again, I assume that this is nothing really new, just a clarification. --Carl --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Fri Jun 28 09:43:51 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA03298 for hpff-interpret-out; Fri, 28 Jun 1996 09:43:51 -0500 (CDT) Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.108]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id JAA03291 for ; Fri, 28 Jun 1996 09:43:42 -0500 (CDT) Received: from post.demon.co.uk ([158.152.1.72]) by relay-4.mail.demon.net id am19050; 28 Jun 96 14:37 GMT Received: from nasoftwr.demon.co.uk ([158.152.18.126]) by relay-3.mail.demon.net id aa20595; 28 Jun 96 15:16 +0100 Received: from ferrari.nasoftware by nasoftwr.demon.co.uk id OAA02871; Fri, 28 Jun 1996 14:40:35 +0100 From: Dave Watson Received: from porsche.nasoftware by ferrari.nasoftware id AA03726; Fri, 28 Jun 96 14:38:45 BST Local-From: dave@ferrari (Dave Watson) Message-Id: <9606281338.AA03726@ferrari.nasoftware> Subject: Re: hpff-interpret: Re: No mapping directives in explicit interface? To: hpff-interpret@cs.rice.edu Date: Fri, 28 Jun 1996 14:38:42 +0100 (BST) In-Reply-To: <9606271515.AA19034@hardy.hpc.pko.dec.com> from "Carl Offner" at Jun 27, 96 11:15:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > > I would say that all three interfaces are non-conforming because the > interfaces do not reflect the mappings. There are, to be sure, > instances in which an interface would not be required -- sub2 is > an example -- but if an interface is present, it should correctly > reflect the mapping of all explicitly mapped arguments. > > Now I don't actually see that the HPF spec says precisely this. > However, it was certainly the understanding behind the explicit > interface proposal. After all, what is the point in requiring an > explicit interface if the explicit interface does not have to describe > the mappings? So maybe (unless some language lawyer can convince us > all that this is already in the spec) we should add a sentence to this > effect. Presumably this would be something like specifying that > the mapping of a dummy argument is a "characteristic" of that > argument, in the terminology of the Fortran standard. > > Again, I assume that this is nothing really new, just a clarification. > I believe Carl has hit the nail on the head. Alignment/Distribution of a dummy SHOULD be a characteristic. With this statement the distinction between prescriptive and descriptive mappings in HPF-1.x becomes redundant naturally since an interface must be present for any mapped object and remapping must be performed if the interface is present for a descriptive mapping. It seems to me to be both logical and in the spirit of F90/F95 that mapping should be a characteristic. After all, F90 requires an interface if TARGET is specified for a dummy but HPF does not (currently) require that a compiler is informed that an argument is/is not distributed and if so how! I believe the current position within HPF-2 to be that an interface is required if there is remapping of the actual and not otherwise. From this I would concur that all 3 interfaces are non-conforming. However, I think that HPF-2 should be explicit and state that hpf directives applied to dummy arguments are characteristics of the dummy. Consider the following : integer :: a(10),b(10) !hpf$ distribute a(block) !hpf$ distribute b(cyclic) call external_sub(a) call external_sub(b) A compiler would be justified in rejecting this program since it can prove that either or both interfaces cause remapping but no interface is present. If we add an interface both calls become legal. By the absence of a specified interface the compiler can infer the f77 interface and thus that the arguments need to be remapped to the default mapping the compiler uses when no mapping is specified. integer :: a(10),b(10) !hpf$ distribute a(block) !hpf$ distribute b(cyclic) interface subroutine external_sub(x) integer :: external_x(*) end subroutine sub end interface call external_sub(a) call external_sub(b) I strongly support the notion that mapping is a characteristic of a dummy and hence that interfaces are required for all procedures with mapped arguments. cheers dave --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------