From owner-hpff-interpret Thu Oct 5 14:04:09 1995 Received: by cs.rice.edu (OAA01601); Thu, 5 Oct 1995 14:04:09 -0500 Received: from mailhub.liverpool.ac.uk by cs.rice.edu (OAA01580); Thu, 5 Oct 1995 14:04:01 -0500 Received: from chad2-13.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Thu, 5 Oct 1995 10:14:31 +0100 From: "Dr A.C. Marshall" Message-Id: <199510050914.KAA09130@chad2-13.liv.ac.uk> Subject: hpff-interpret: Fortran 95 To: hpff-interpret@cs.rice.edu Date: Thu, 5 Oct 1995 10:14:16 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 972 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 may well have missed something here but does the HPFF intend to `redraft' the HPF V1.1 spec to define the language binding in terms of Fortran 95 or is that going to be left to HPF 2? For example, I am thinking of the argument lists to tghe reduction functions MINVAL, PRODUCT etc. Also there are some very "sensible" extensions in allowing user defined functions in specification expressions. I guess as F95 is a superset of F90 vendors could provide the new F95 features as extensions to HPF V1.1. It would seem a sensible thing to do. Adam Marshall -- | AC Marshall | Computing Services Department, | University of Liverpool, | PO Box 147. | L69 3BX | UK | email: adamm@liv.ac.uk | Tel: 0151-794 3722 | Fax: 0151-794 3759 | --------------------------------------------------------------------------- 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 Oct 5 14:35:45 1995 Received: by cs.rice.edu (OAA04810); Thu, 5 Oct 1995 14:35:45 -0500 Received: from coral.llnl.gov by cs.rice.edu (OAA04803); Thu, 5 Oct 1995 14:35:39 -0500 Message-Id: <199510051935.OAA04803@cs.rice.edu> Received: by coral.llnl.gov (1.38.110.45/16.2) id AA282611685; Thu, 5 Oct 1995 12:34:45 -0700 Date: Thu, 5 Oct 1995 12:34:45 -0700 From: Mary E Zosel To: adamm@liverpool.ac.uk Subject: hpff-interpret: HPF and F95 Cc: hpff-interpret@cs.rice.edu Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 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. --------------------------------------------------------------------------- Adam We plan to address F95 in HPF2 ... timing of approval for F95 is a bit awkward, since we may be a bit ahead of F95 formal approval. But the spirit of the group is that full HPF is F95 + ... It is highly unlikely that we will make these changes retroactive to the definition of HPF1.1 specification. As you suggest, that would be left to the vendors. We are not in the mode of making extensions to HPF1.1 at this time. -mary zosel- --------------------------------------------------------------------------- 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 Oct 5 15:09:30 1995 Received: by cs.rice.edu (PAA06302); Thu, 5 Oct 1995 15:09:30 -0500 Received: from noel.cs.rice.edu by cs.rice.edu (PAA06289); Thu, 5 Oct 1995 15:09:25 -0500 Received: from [128.42.1.213] by noel.cs.rice.edu (PAA23514); Thu, 5 Oct 1995 15:09:23 -0500 Date: Thu, 5 Oct 1995 15:09:23 -0500 X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Dr A.C. Marshall" , hpff-interpret@cs.rice.edu From: chk@cs.rice.edu (Chuck Koelbel) Subject: Re: hpff-interpret: Fortran 95 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 may well have missed something here but does the HPFF intend to `redraft' >the HPF V1.1 spec to define the language binding in terms of Fortran 95 or >is that going to be left to HPF 2? For example, I am thinking of the >argument lists to tghe reduction functions MINVAL, PRODUCT etc. Also there >are some very "sensible" extensions in allowing user defined functions in >specification expressions. > >I guess as F95 is a superset of F90 vendors could provide the new F95 >features as extensions to HPF V1.1. It would seem a sensible thing to do. > >Adam Marshall The short answer is, "We'll leave Fortran 95 up to HPF 2.0." I agree that F95 has some nice features, taken from HPF and from other places. (I can't speak for the whole HPFF working group, but I think this is a common view.) Plans are to restructure the HPF 2.0 specification to be based on F95, but intermediate versions (corrections, clarifications, interpretations) will continue to be based on F90. Think of this as bundling all the big changes into one package. As with (almost) any language, vendors can add their own extensions. Their customers can decide whether they want to pay for worthwhile features that may be nonportable to other platforms. F95 extensions to HPF sound very feasible, and should be more portable than extensions like "brand X active objects". (Well, I'm *trying* not to slam any particular company...) Chuck Koelbel --------------------------------------------------------------------------- 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 Sat Oct 7 13:55:19 1995 Received: by cs.rice.edu (NAA14489); Sat, 7 Oct 1995 13:55:19 -0500 (CDT) Received: from pacific.pgroup.com by cs.rice.edu (NAA14476); Sat, 7 Oct 1995 13:55:12 -0500 (CDT) Received: from indy.pgroup.com (indy [192.124.124.34]) by pacific.pgroup.com (8.6.12/8.6.11) with ESMTP id LAA02098 for ; Sat, 7 Oct 1995 11:55:05 -0700 From: Larry Meadows Received: (lfm@localhost) by indy.pgroup.com (8.6.11/8.6.11) id SAA26547 for hpff-interpret@cs.rice.edu; Sat, 7 Oct 1995 18:55:03 GMT Date: Sat, 7 Oct 1995 18:55:03 GMT Message-Id: <199510071855.SAA26547@indy.pgroup.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: remapping of arguments inside independent 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 Section 4.4 of the standard, one of the conditions on INDEPENDENT is that realignment and redistribution cannot occur, since they may change the processor storing a particular array element. I would argue that the same reasoning applies to remapping of arguments in subroutines called inside of INDEPENDENT DO loops. For example: !hpf$ distribute a(block) !hpf$ indepedent do i = 1,n call sub(a) enddo subroutine sub(a) real a(:) !hpf$ distribute a(cyclic) ... return end >From an implementation point of view, remapping of arguments is a collective operation, just as is realignment or redistribution, so is difficult to implement inside INDEPENDENT DO loops. Couple of other points: - Would be nice to have some examples in 4.4.1 where subroutines were called, legally and illegally. - I seem to recall that we decided that local variables of subroutines called inside INDEPENDENT DO loops were automatically NEW (and I assume that this doesn't apply to SAVE or COMMON variables). Is this documented anywhere? Thanks. 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 Fri Oct 27 09:02:42 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA07499 for hpff-interpret-out; Fri, 27 Oct 1995 09:02:42 -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 JAA07489 for ; Fri, 27 Oct 1995 09:02:37 -0500 (CDT) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2868; Fri, 27 Oct 95 10:02:34 EDT Received: by TOROLAB (XAGENTA 4.0) id 3349; Fri, 27 Oct 1995 10:05:24 -0400 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA08023; Fri, 27 Oct 1995 10:02:29 -0400 From: (Henry Zongaro) Message-Id: <9510271402.AA08023@twinpeaks.torolab.ibm.com> Subject: hpff-interpret: GLOBAL_TO_LOCAL (fwd) To: hpff-interpret@cs.rice.edu (HPPF Interpretations) Date: Fri, 27 Oct 1995 10:02:28 -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. --------------------------------------------------------------------------- Hi, I sent this out a few days ago, but I never saw it reflected so I thought I'd send it out again. Sorry if this is a duplicate for anyone. Thanks, Henry ------------------------------------------------------------------------------- Forwarded message: From henry Mon Oct 23 17:26:07 1995 Hello, A number of the procedures in the HPF_LOCAL_LIBRARY refer to their arguments as containing or receiving "coordinates". It's not clear whether the values returned or required are supposed to be based on the corresponding lower bounds of the array (or processor as the case may be) or whether they should be one-based. For example, PROGRAM P INTERFACE EXTRINSIC(HPF_LOCAL) SUBROUTINE SUB(D) INTEGER D(4:) !HPF$ PROCESSORS PROC(NUMBER_OF_PROCESSORS()) !HPF$ DISTRIBUTE D(BLOCK) ONTO PROC END SUBROUTINE SUB END INTERFACE INTEGER A(5:10) CALL SUB(A) END PROGRAM P EXTRINSIC(HPF_LOCAL) SUBROUTINE SUB(D) USE HPF_LOCAL_LIBRARY INTEGER D(4:), L(1) CALL GLOBAL_TO_LOCAL(D, G_INDEX=(/5/), L_INDEX=L) END SUBROUTINE SUB Assuming this program is run on one processor, what should be the value of L after the call to GLOBAL_TO_LOCAL? If G_INDEX and L_INDEX are indices that are based on the actual lower bounds of A and D, respectively, then G_INDEX=(/5/) would refer to the first element of A, and the corresponding element of D would be D(4), and so L_INDEX should be (/4/). If G_INDEX and L_INDEX are based on one, then G_INDEX=(/5/) would refer to the fifth element of A (i.e, A(9)), and the corresponding element of D would be D(8), which is the fifth element of D, and so L_INDEX should be (/5/). This shows up in ABSTRACT_TO_PHYSICAL and PHYSICAL_TO_ABSTRACT (the INDEX argument), LOCAL_TO_GLOBAL and GLOBAL_TO_LOCAL (the G_INDEX and L_INDEX arguments) and (I think) the results of LOCAL_LINDEX and LOCAL_UINDEX. One thing to consider is that the results of GRADE_UP and GRADE_DOWN seem to be values that can be used to index the array that's been sorted, but the results of MAXLOC and MINLOC are one-based, so there's a precedent for each. (Were the results of GRADE_UP and GRADE_DOWN intentionally designed to be different from those of MAXLOC and MINLOC?) It should also be noted that the INDEX argument of ABSTRACT_TO_PHYSICAL and PHYSICAL_TO_ABSTRACT gives indices in a processor arrangement, but there's no direct way of finding out the bounds of such a processor arrangement - HPF_DISTRIBUTION and GLOBAL_DISTRIBUTION will only give you the *shape*. 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 ---------------------------------------------------------------------------