From owner-hpff-interpret Mon Mar 4 15:02:54 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id PAA14716 for hpff-interpret-out; Mon, 4 Mar 1996 15:02:54 -0600 (CST) Received: from cupid.cs.utk.edu (CUPID.CS.UTK.EDU [128.169.94.221]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id PAA14707 for ; Mon, 4 Mar 1996 15:02:47 -0600 (CST) From: rwhaley@cs.utk.edu Received: by cupid.cs.utk.edu (cf v2.11c-UTK) id QAA28806; Mon, 4 Mar 1996 16:02:32 -0500 Date: Mon, 4 Mar 1996 16:02:32 -0500 Message-Id: <199603042102.QAA28806@cupid.cs.utk.edu> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: external issues: extrinsic(f77_local) Cc: dongarra@cs.utk.edu, hammarli@cs.utk.edu, rwhaley@cs.utk.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. --------------------------------------------------------------------------- Hi, I am a research associate with Jack Dongarra. I have been looking at providing an HPF interface to ScaLAPACK, our linear algebra Fortran77 message passing library. In the course of this work, I've run into several problems involved in calling an extrinsic routine. Most of these problems seem to be in the present generation of compilers. However, I've run into one that seems to be a function of the HPF specification, which I believe could be fixed by a small addition to the extrinsic section. I include below a small latex note on the issue. I would be happy to provide further information or help if I can. I have also been reading the HPFF minutes for information on how HPF is going to look in the future. I was rather alarmed to note that kernel HPF appears to be heading towards no support for cyclic(n). I assume the committee is assuming that algorithmic blocking will ameliorate the performance hit for such a decision? I know that our own library does not yet support algorithmic blocking for many routines; where it is absent, a cyclic(1) distribution yields minimal performance . . . I am not abreast of all of the literature on the subject, but it is not clear to me that all algorithms can efficiently use algorithmic blocking . . . Perhaps I don't understand what kernel HPF really is. Is it HPF2.0's subset HPF? Or is it features the compiler should support efficiently, with other features supported but not with the same degree of optimality? Thanks for your help, Clint \documentstyle[11pt]{article} \topmargin .5in \pagestyle{myheadings} \markboth{\underline{\bf DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT}} {\underline{\bf DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT}} \textwidth=6in \textheight=8.5in \hoffset = -.6in \voffset = -.6in \title{Passing multidimensional arrays from HPF to extrinsic routines} \author{ R. Clint Whaley \thanks{ Dept. of Computer Sciences, Univ. of TN, Knoxville, TN 37996, {\tt rwhaley@cs.utk.edu} } } \begin{document} \maketitle \begin{abstract} Under the present extrinsic interface rules, it is not possible to portably pass multidimensional arrays from HPF to a language such as Fortran77 or C. In this paper we discuss the problem and suggest some solutions. \end{abstract} \vspace*{1in} \centerline{ \bf \Large \underline{DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT} } \newpage We believe that an important area of interfacing HPF routines and local Fortran77 has been overlooked. The problem involves the translation of a HPF/F90 assumed {\em shape} array to a F77 assumed {\em size} array. This problem may be overcome in F90 by specifying an explicit interface. This approach is illustrated in figure~\ref{fig-f902f77}. Obviously, if the compiler has not already stored the indicated (sub)array in an array whose first dimension is equal to the {\tt SIZE} of the array, it will have to allocate space and copy the array. \begin{figure} \begin{verbatim} SUBROUTINE F90_TO_F77(A) REAL, INTENT(INOUT) :: A(:,:) INTEGER :: M, N, LDA INTERFACE SUBROUTINE F77ROUT(M, N, A, LDA) INTEGER, INTENT(IN) :: M, N, LDA REAL, INTENT(INOUT) :: A(LDA,*) END SUBROUTINE F77ROUT END INTERFACE M = SIZE(A, 1) N = SIZE(A, 2) LDA = M CALL F77ROUT(M, N, A, LDA) RETURN END \end{verbatim} \caption{A F90 routine passing a 2D array to a F77 routine\label{fig-f902f77}} \end{figure} Note that in distributed memory terms, leading dimension (\verb+LDA+ in the above example) is an inherently {\em local} quantity: it indicates the memory stride between elements in a row. Thus the F90 approach cannot be directly utilized in HPF, since the interface described by HPF is {\em global}. This oversight means that only 1D arrays may be standardly passed from HPF to external languages such as C or Fortran77 (this is obviously true because it is impossible to determine how the compiler has locally laid out the matrix, and thus it will be impossible to do indexing on such arrays). This means that codes wishing to pass arrays with greater than 1 dimension will have to be compiler specific (actually, compiler version specific). Compilers supporting extrinsic(f90\_local) should not have this problem. There, the user may pass the HPF matrix to a f90\_local routine which takes the matrix as assumed shape. The f90\_local routine may then use the code in figure~\ref{fig-f902f77} to pass the local array to the Fortran77 code. Compilers which support only f77\_local will not have this option. This makes f77\_local less useful as an interface. Obviously, specific extrinsics are not part of the HPF standard, so it is not surprising that this issue has not been addressed by HPF. However, just as the local library can be part of the standard for those compilers supporting hpf\_local, a solution to this problem can be adopted as part of the standard for those compilers choosing to support f77\_local. We propose a two-fold solution to this problem. The first takes the form of an added distribution directive: \\ {\tt !HPF\$ ASSUMMED\_SIZE :: A(LD1, LD2, $\dots$, *)} \\ This command, which is legal only in an interface to an extrinsic routine accepting assumed size arrays, asserts that the dimensions of the local matrix match the dimensions specified by the parameters {LD1, LD2, \dots}. This is the minimal extension required to make multidimensional arrays usable across languages. The user can fill in minimal values for {\tt LDx} by the appropriate call to {\tt SIZE} from an {\tt HPF\_LOCAL} routine (assuming the compiler supports {\tt HPF\_LOCAL}). This fix has a weakness in common with that used by F90, however. To whit, if the compiler is currently storing the array with a non-minimal dimension, a data copy will be dictated by the interface which, at least theoretically, could have been avoided. In today's compilers, data copies occur on most subarray accesses, so this point is not as significant as it might be. However, as compilers become more efficient, this should no longer be the case, and the implied data copy in forcing the user to ``guess'' the dimension presently being used may become significant. We therefore believe that the HPF standard should encourage vendors supporting extrinsic interfaces to include the routine:\\ {\tt INTEGER FUNCTION LOCAL\_DIM(ARRAY, DIM)}\\ \verb+ +Returns the local number of elements of ARRAY along the axis DIM. With this routine, the user can query the dimensions of the array the compiler will use if array ARRAY is passed to an extrinsic routine. This should allow the user to find the correct dimensions to avoid dictating a data copy, if he so chooses. \end{document} --------------------------------------------------------------------------- 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 Mar 8 07:29:57 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id HAA22784 for hpff-interpret-out; Fri, 8 Mar 1996 07:29:57 -0600 (CST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id HAA22779 for ; Fri, 8 Mar 1996 07:29:54 -0600 (CST) Received: from mpsg.hpc.pko.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA30758; Fri, 8 Mar 1996 08:24:02 -0500 Received: by mpsg.hpc.pko.dec.com; id AA05463; Fri, 8 Mar 1996 08:30:19 -0500 From: offner@hpc.pko.dec.com (Carl Offner) Received: by sable1.hpc.pko.dec.com; (5.65/1.1.8.2/21Dec95-1127AM) id AA19884; Fri, 8 Mar 1996 08:24:08 -0500 Date: Fri, 8 Mar 1996 08:24:08 -0500 Message-Id: <9603081324.AA19884@sable1.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: CCI request concerning HPF_LOCAL inquiry intrinsics 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 am submitting this as a CCI request. We have run into some problems with the hpf local inquiry intrinsics (e.g., GLOBAL_TO_LOCAL, GLOBAL_UBOUND, etc.). These intrinsics are described as returning information about the "actual HPF global array argument associated with an HPF_LOCAL dummy array argument". The problems we see are these: 1. The actual argument might be an array expression. This wouldn't be a problem for things like array bounds information -- I think Fortran already has a consistent way of defining such things in such cases (e.g. for assumed-shape arrays). But what about the MAPPING of the actual? Expressions have no mappings, but these intrinsics can be used to extract global mapping information. 2. The actual argument might be remapped by the compiler in the course of processing the subroutine call. (This would commonly happen if the dummy argument had a different mapping.) The user really is then interested in the "remapped actual". 3. This could also happen if the compiler (for whatever reasons of its own) decides to use a different mapping than that specified by the programmer. Compilers today are not going to do that, but in the future one could imagine an optimizing compiler with that kind of capability. The user certainly wants information about the real object, not about whatever appears syntactically specified. 4. Finally, there is an additional problem: There are mappings that can be specified in more than one way. A compiler will typically not store the source of the mapping directives -- it will pick some internal representation for the mapping. When it reports information from this internal representation, it may look superficially different to the programmer, even though it amounts to the same thing. Furthermore, the representation may depend on things like the number of processors being compiled for. To take an extreme case (one could make up a more realistic case; but this exhibits the problem well enough), suppose the compiler is told to compile an HPF program for execution on 1 processor. It is reasonable for the compiler to decide internally that all mappings are serial, even if they were specified as BLOCK in the source program. Certainly there would be nothing wrong with reporting a serial mapping, since it would describe precisely the data layout; but it's not what either the actual or dummy arguments were described as in the program source. The point is that there is really no need for the results of these inquiry intrinsics to be tied syntactically to the actual argument. All the user needs is the information necessary to write explicit message-passing code. The compiler should be able to use whatever internal representation is consistent with what the user has written, and to report information based on this internal representation. I think that's what the user really wants, in any case. ------- Here is the idea of what we would like to say: Since the ONLY reason that a user would ever want to call such a routine is to extract information in order to perform explicit message-passing, we think that the routines ought to be defined to return information about "the global object of which the dummy argument is a local section" with the understanding that this "global object" is implementation-defined. The problem, of course, is that I don't know a standard computer-language formal way to state this. --Carl Offner offner@hpc.pko.dec.com --------------------------------------------------------------------------- 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 Mar 8 12:34:18 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA03340 for hpff-interpret-out; Fri, 8 Mar 1996 12:34:18 -0600 (CST) 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 MAA03330; Fri, 8 Mar 1996 12:34:12 -0600 (CST) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Mar 1996 12:34:32 -0600 To: offner@hpc.pko.dec.com (Carl Offner) From: chk@cs.rice.edu (Chuck Koelbel) Subject: Re: hpff-interpret: CCI request concerning HPF_LOCAL inquiry intrinsics 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. --------------------------------------------------------------------------- I'll try to get straight to the punch line. Let me admit up front, however, that I'm a little hazy on some aspects of EXTRINSIC. >Here is the idea of what we would like to say: Since the ONLY reason >that a user would ever want to call such a routine is to extract >information in order to perform explicit message-passing, we think >that the routines ought to be defined to return information about > > "the global object of which the dummy argument is a > local section" > >with the understanding that this "global object" is >implementation-defined. > >The problem, of course, is that I don't know a standard >computer-language formal way to state this. I thought this is what the original language meant. (Or was intended to mean...) I think of it this way: The EXTRINSIC callee gets an area of memory (the dummy argument) and a data descriptor (not directly visible) from the caller. GLOBAL_FOO and FOO_GLOBAL routines extract information otherwise inaccessible from the descriptor. [Suddenly I'm suspicious that these routines should be intrinsics - else it's hard to explain where they get their arguments...] The "actual HPF global array argument" is an array with (a copy of) that descriptor and area of memory. This may not correspond to any particular syntactic element of the program. I would agree that the current wording isn't crystal clear (despite being written by Guy Steele, if I remember right). But then the whole idea of EXTRINSIC procedures has always been kind of hard for me to grasp... Starting from that premise, let's see if any of these problems get clearer. At 08:24 03/08/96, Carl Offner wrote: > >The problems we see are these: > >1. The actual argument might be an array expression. This wouldn't >be a problem for things like array bounds information -- I think >Fortran already has a consistent way of defining such things in such >cases (e.g. for assumed-shape arrays). But what about the MAPPING of >the actual? Expressions have no mappings, but these intrinsics can be >used to extract global mapping information. The mental model seems to handle this OK in common cases- the caller has to build a descriptor, which may not correspond to any array variable or section thereof. Indirection arrays break the model by making the descriptor poorly defined. But they also break INTENT(OUT) and assumed-shape dummies. HPF has rules for when descriptive mappings can be used for dummy arguments (i.e. when mappings are identical). Cant we amend the standard so that GLOBAL_TO_LOCAL & friends are implementation-dependent when a descriptive mapping cannot be used? A note to implementors might say "We suggest that the compiler create the simplest possible descriptor for the other cases - for example, align the result of an array expression with one of its inputs." >2. The actual argument might be remapped by the compiler in the >course of processing the subroutine call. (This would commonly happen >if the dummy argument had a different mapping.) The user really is >then interested in the "remapped actual". This is definitely unclear in the current language. Using something along the lines of the mental model, we have to say "do the remapping before constructing the descriptor". >3. This could also happen if the compiler (for whatever reasons of its >own) decides to use a different mapping than that specified by the >programmer. Compilers today are not going to do that, but in the >future one could imagine an optimizing compiler with that kind of >capability. The user certainly wants information about the real >object, not about whatever appears syntactically specified. The same problem (theoretically) occurs in regular HPF code if the compiler chooses its own distributions. HPF_DISTRIBUTE may then return misleading information. The onus is on the compiler to ensure that if it ignores user advice, then the results remain consistent. In particular, GLOBAL_TO_LOCAL should produce an index that gets you to the expected element. (In regular HPF, REDISTRIBUTE must move the right elements to the right places.) Two mechanisms have been suggested for doing this: 1. Have the HPF library routines return the truth about what the compiler is doing. This basically presumes run-time descriptors are queried (and updated). 2. Before any HPF library routine is called, remap the data back where the user said it should go, return the "expected" result, then remap data to where the compiler thinks it should be. As an optimization, the compiler can eliminate the remappings as dead code. The first option is considered preferable. You seem to assume that the "actual" is the syntactic element - I think it is the runtime object. >4. Finally, there is an additional problem: There are mappings that >can be specified in more than one way. A compiler will typically not >store the source of the mapping directives -- it will pick some >internal representation for the mapping. When it reports information >from this internal representation, it may look superficially different >to the programmer, even though it amounts to the same thing. You can say the same thing about HPF_DISTRIBUTE in regular HPF. My interpretation is that the HPF library inquiries can return any valid representation of the mapping. Since the representations correspond to equivalent mappings, this should not matter to the user. (I suppose some users will try to reverse-engineer the optimizations on address arithmetic this way... It will not matter to the *normal* user.) Is there something in the writeup that says "the mapping specified in the syntax"? >The point is that there is really no need for the results of these >inquiry intrinsics to be tied syntactically to the actual argument. I agree that there is no need to tie them to the syntax. Maybe it's just my warped point of view, but I don't think they are... 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 Fri Mar 8 19:43:14 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id TAA00451 for hpff-interpret-out; Fri, 8 Mar 1996 19:43:14 -0600 (CST) Received: from moe.rice.edu (moe.rice.edu [128.42.5.4]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id TAA00405 for ; Fri, 8 Mar 1996 19:42:59 -0600 (CST) Received: from pacific.pgroup.com (pacific.pgroup.com [192.124.124.8]) by moe.rice.edu (8.7.1/8.7.1) with SMTP id TAA23466 for ; Fri, 8 Mar 1996 19:28:46 -0600 (CST) Received: (from lfm@localhost) by pacific.pgroup.com (8.6.12/8.6.11) id RAA25999 for hpff-interpret@cs.rice.edu; Fri, 8 Mar 1996 17:28:43 -0800 Message-Id: <199603090128.RAA25999@pacific.pgroup.com> Subject: hpff-interpret: Forwarded mail... To: hpff-interpret@cs.rice.edu Date: Fri, 8 Mar 1996 17:28:42 -0800 (PST) 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. --------------------------------------------------------------------------- Since we're on the topic of hpf_local: ! The question is, should this global_lbound return 1 or -104? program xc06 interface extrinsic (hpf_local) function vet(array2,results) integer vet integer, dimension (:,:,:,:,:,:,:) :: array2 !HPF$ DISTRIBUTE(BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK)::array2 integer,intent(out):: results end function end interface integer, dimension(-104:-100,2,0:1,-1:1,1:3,-1:0,1:2):: a2 integer results !HPF$ DISTRIBUTE(BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK)::a2 integer ::a_res integer:: num_procs a_res=vet(a2,results) print *,results end extrinsic (hpf_local) function vet(array2,results) use hpf_library use hpf_local_library integer vet integer, dimension (:,:,:,:,:,:,:) :: array2 integer,intent(out):: results results=global_lbound(array2, 1) return end --------------------------------------------------------------------------- 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 Mar 11 11:05:57 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id LAA27101 for hpff-interpret-out; Mon, 11 Mar 1996 11:05:57 -0600 (CST) 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 LAA27095 for ; Mon, 11 Mar 1996 11:05:52 -0600 (CST) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0040; Mon, 11 Mar 96 12:05:40 EST Received: by TOROLAB (XAGENTA 4.0) id 0831; Mon, 11 Mar 1996 12:08:21 -0500 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA35842; Mon, 11 Mar 1996 12:05:32 -0500 From: (Henry Zongaro) Message-Id: <9603111705.AA35842@twinpeaks.torolab.ibm.com> Subject: Re: hpff-interpret: CCI request concerning HPF_LOCAL inquiry intrinsics To: chk@cs.rice.edu (Chuck Koelbel) Date: Mon, 11 Mar 1996 12:05:30 -0500 (EST) Cc: offner@hpc.pko.dec.com, hpff-interpret@cs.rice.edu In-Reply-To: from "Chuck Koelbel" at Mar 8, 96 12:34:32 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. --------------------------------------------------------------------------- Hello, I just have a couple of points relating to all of this. > >Here is the idea of what we would like to say: Since the ONLY reason > >that a user would ever want to call such a routine is to extract > >information in order to perform explicit message-passing, we think > >that the routines ought to be defined to return information about > > > > "the global object of which the dummy argument is a > > local section" > > > >with the understanding that this "global object" is > >implementation-defined. > > > >The problem, of course, is that I don't know a standard > >computer-language formal way to state this. > > I thought this is what the original language meant. (Or was intended to > mean...) > > > I think of it this way: > > The EXTRINSIC callee gets an area of memory (the dummy argument) and a > data descriptor (not directly visible) from the caller. > > GLOBAL_FOO and FOO_GLOBAL routines extract information otherwise > inaccessible from the descriptor. [Suddenly I'm suspicious that these > routines should be intrinsics - else it's hard to explain where they get > their arguments...] > > The "actual HPF global array argument" is an array with (a copy of) that > descriptor and area of memory. This may not correspond to any particular > syntactic element of the program. > > > I would agree that the current wording isn't crystal clear (despite being > written by Guy Steele, if I remember right). But then the whole idea of > EXTRINSIC procedures has always been kind of hard for me to grasp... > > > Starting from that premise, let's see if any of these problems get clearer. > > At 08:24 03/08/96, Carl Offner wrote: > > > >The problems we see are these: > > > >1. The actual argument might be an array expression. This wouldn't > >be a problem for things like array bounds information -- I think > >Fortran already has a consistent way of defining such things in such > >cases (e.g. for assumed-shape arrays). But what about the MAPPING of > >the actual? Expressions have no mappings, but these intrinsics can be > >used to extract global mapping information. > > The mental model seems to handle this OK in common cases- the caller has to > build a descriptor, which may not correspond to any array variable or > section thereof. Indirection arrays break the model by making the > descriptor poorly defined. But they also break INTENT(OUT) and > assumed-shape dummies. > > HPF has rules for when descriptive mappings can be used for dummy arguments > (i.e. when mappings are identical). Cant we amend the standard so that > GLOBAL_TO_LOCAL & friends are implementation-dependent when a descriptive > mapping cannot be used? A note to implementors might say "We suggest that > the compiler create the simplest possible descriptor for the other cases - > for example, align the result of an array expression with one of its > inputs." I think the HPF document already says enough. If you check out Section 3.10, the second paragraph states that, "If there is no explicit interface, then actual arguments that are whole arrays or array sections not involving vector subscripts may be remapped at the discretion of the language processor; the values of other expressions may be remapped in any manner at the discretion of the language processor." This implies to me that even though the user cannot specify a mapping for an expression, the expression will nevertheless have a mapping. > >2. The actual argument might be remapped by the compiler in the > >course of processing the subroutine call. (This would commonly happen > >if the dummy argument had a different mapping.) The user really is > >then interested in the "remapped actual". > > This is definitely unclear in the current language. > > Using something along the lines of the mental model, we have to say "do the > remapping before constructing the descriptor". The second paragraph of 3.10 states that, "If there is an explicit interface for the called subprogram, . . . the actual argument will be remapped if necessary to conform to the directives in the explicit interface." This describes remapping as affecting the actual argument - it doesn't speak in terms of an actual that the user specified vs. a remapped actual. There is only one actual, it is remapped on the call and becomes associated with a dummy argument; when the user inquires about the mapping of the associated actual, the information returned is about the mapping the actual has while it's associated with the dummy. > > >3. This could also happen if the compiler (for whatever reasons of its > >own) decides to use a different mapping than that specified by the > >programmer. Compilers today are not going to do that, but in the > >future one could imagine an optimizing compiler with that kind of > >capability. The user certainly wants information about the real > >object, not about whatever appears syntactically specified. > > The same problem (theoretically) occurs in regular HPF code if the compiler > chooses its own distributions. HPF_DISTRIBUTE may then return misleading > information. > > The onus is on the compiler to ensure that if it ignores user advice, then > the results remain consistent. In particular, GLOBAL_TO_LOCAL should > produce an index that gets you to the expected element. (In regular HPF, > REDISTRIBUTE must move the right elements to the right places.) Two > mechanisms have been suggested for doing this: > > 1. Have the HPF library routines return the truth about what the compiler > is doing. This basically presumes run-time descriptors are queried (and > updated). > > 2. Before any HPF library routine is called, remap the data back where the > user said it should go, return the "expected" result, then remap data to > where the compiler thinks it should be. As an optimization, the compiler > can eliminate the remappings as dead code. > > The first option is considered preferable. > > You seem to assume that the "actual" is the syntactic element - I think it > is the runtime object. > > >4. Finally, there is an additional problem: There are mappings that > >can be specified in more than one way. A compiler will typically not > >store the source of the mapping directives -- it will pick some > >internal representation for the mapping. When it reports information > >from this internal representation, it may look superficially different > >to the programmer, even though it amounts to the same thing. > > You can say the same thing about HPF_DISTRIBUTE in regular HPF. > > My interpretation is that the HPF library inquiries can return any valid > representation of the mapping. Since the representations correspond to > equivalent mappings, this should not matter to the user. (I suppose some > users will try to reverse-engineer the optimizations on address arithmetic > this way... It will not matter to the *normal* user.) > > Is there something in the writeup that says "the mapping specified in the > syntax"? > > >The point is that there is really no need for the results of these > >inquiry intrinsics to be tied syntactically to the actual argument. > > I agree that there is no need to tie them to the syntax. > Maybe it's just my warped point of view, but I don't think they are... > > Chuck 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 Mar 11 12:03:07 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA00250 for hpff-interpret-out; Mon, 11 Mar 1996 12:03:07 -0600 (CST) 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 MAA00242 for ; Mon, 11 Mar 1996 12:03:02 -0600 (CST) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1977; Mon, 11 Mar 96 13:02:51 EST Received: by TOROLAB (XAGENTA 4.0) id 0861; Mon, 11 Mar 1996 13:05:12 -0500 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA35917; Mon, 11 Mar 1996 13:02:26 -0500 From: (Henry Zongaro) Message-Id: <9603111802.AA35917@twinpeaks.torolab.ibm.com> Subject: Re: hpff-interpret: Forwarded mail... To: lfm@pgroup.com (Larry Meadows) Date: Mon, 11 Mar 1996 13:02:24 -0500 (EST) Cc: hpff-interpret@cs.rice.edu In-Reply-To: <199603090128.RAA25999@pacific.pgroup.com> from "Larry Meadows" at Mar 8, 96 05:28:42 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. --------------------------------------------------------------------------- Hi Larry, > Since we're on the topic of hpf_local: > > > ! The question is, should this global_lbound return 1 or -104? > program xc06 > interface > extrinsic (hpf_local) function vet(array2,results) > integer vet > integer, dimension (:,:,:,:,:,:,:) :: array2 > !HPF$ DISTRIBUTE(BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK)::array2 > integer,intent(out):: results > end function > end interface > > integer, dimension(-104:-100,2,0:1,-1:1,1:3,-1:0,1:2):: a2 > integer results > !HPF$ DISTRIBUTE(BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK)::a2 > integer ::a_res > integer:: num_procs > a_res=vet(a2,results) > print *,results > end > > extrinsic (hpf_local) function vet(array2,results) > use hpf_library > use hpf_local_library > integer vet > integer, dimension (:,:,:,:,:,:,:) :: array2 > integer,intent(out):: results > results=global_lbound(array2, 1) > return > end The value returned should be -104. This is consistent with the examples shown under GLOBAL_LBOUND and GLOBAL_UBOUND. 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 Mar 20 11:56:19 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id LAA10800 for hpff-interpret-out; Wed, 20 Mar 1996 11:56:19 -0600 (CST) Received: from cupid.cs.utk.edu (CUPID.CS.UTK.EDU [128.169.94.221]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id LAA10791 for ; Wed, 20 Mar 1996 11:56:13 -0600 (CST) From: rwhaley@cs.utk.edu Received: by cupid.cs.utk.edu (cf v2.11c-UTK) id MAA00578; Wed, 20 Mar 1996 12:56:12 -0500 Date: Wed, 20 Mar 1996 12:56:12 -0500 Message-Id: <199603201756.MAA00578@cupid.cs.utk.edu> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: simple HPF_TEMPLATE clarification Cc: rwhaley@cs.utk.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. --------------------------------------------------------------------------- Hi, I'm looking at "High Performance Fortran Language Specification", May 3, 1993 Version 1.0. Under the description of HPF_TEMPLATE, is the following wording: ... HPF_TEMPLATE returns information concerning the variable from the template's point of view (assuming the alignment is to a template rather than an array) ... My understanding of this routine is that it can give information about any ALIGNEE, even those not ultimately aligned to an !HPF$ TEMPLATE. Rather, I interpret this to reference to be to the more general definition of template, "an index space". Can you tell me if this is correct? If so, it might be helpful to disambiguate the above sentence . . . Thanks, Clint --------------------------------------------------------------------------- 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 Mar 22 17:38:27 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id RAA17804 for hpff-interpret-out; Fri, 22 Mar 1996 17:38:27 -0600 (CST) Received: from cupid.cs.utk.edu (CUPID.CS.UTK.EDU [128.169.94.221]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id RAA17799 for ; Fri, 22 Mar 1996 17:38:20 -0600 (CST) From: rwhaley@cs.utk.edu Received: by cupid.cs.utk.edu (cf v2.11c-UTK) id SAA06360; Fri, 22 Mar 1996 18:38:20 -0500 Date: Fri, 22 Mar 1996 18:38:20 -0500 Message-Id: <199603222338.SAA06360@cupid.cs.utk.edu> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: clarification for EXTRINSIC(HPF_LOCAL) Cc: rwhaley@cs.utk.edu, susan@cs.utk.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. --------------------------------------------------------------------------- Hi, I am looking at the HTML version of the HPF language specification, version 1.1. It says: >A dummy array argument of an EXTRINSIC(HPF_LOCAL) routine must have assumed >shape, even when it is explicit shape in the interface. Note that, in general, >the shape of a dummy array argument differs from the shape of the corresponding >actual argument, unless there is a single executing processor. I think this statement is misleading. Is it true that all HPF_LOCAL routines are constrained to accept only assumed shape arrays, or is it only HPF_LOCAL routines which are called from global HPF that have this restriction? The reason I ask is that we have Fortran77 code which we are hoping to access from HPF. The easiest route to do this is to have the HPF routine call an HPF_LOCAL routine with our arrays passed in as assumed shape. Then, since HPF_LOCAL is a superset of Fortran77, we declare our Fortran77 routine as another HPF_LOCAL routine taking an assumed size array (required by Fortran77). So, my question is: can HPF_LOCAL routines which will not be called from global HPF take assumed size arrays? If so, I think a slight rewording of the standard might help make this apparent. Thanks, Clint --------------------------------------------------------------------------- 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 Mar 25 07:58:48 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id HAA08022 for hpff-interpret-out; Mon, 25 Mar 1996 07:58:48 -0600 (CST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id HAA08017 for ; Mon, 25 Mar 1996 07:58:41 -0600 (CST) Received: from mpsg.hpc.pko.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA07082; Mon, 25 Mar 1996 08:48:43 -0500 Received: by mpsg.hpc.pko.dec.com; id AA29210; Mon, 25 Mar 1996 08:55:15 -0500 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 AA17720; Mon, 25 Mar 1996 08:48:34 -0500 Date: Mon, 25 Mar 1996 08:48:34 -0500 Message-Id: <9603251348.AA17720@hardy.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: Subject: Re: clarification for EXTRINSIC(HPF_LOCAL) Cc: offner@hpc.pko.dec.com, rwhaley@cs.utk.edu, susan@cs.utk.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. --------------------------------------------------------------------------- There is no constraint stopping an HPF_LOCAL routine from calling a Fortran 77 routine, as far as I know. In fact, a standard way of calling such routines would be, as you suggest, to use the HPF_LOCAL routine as a wrapper to set up the argument passing for the Fortran 77 or Fortran 90 routine it then calls. Such a routine could be declared, for example, as EXTRINSIC(F90_LOCAL). (You have to declare it as *something*; otherwise the default is that it is also considered to be HPF_LOCAL.) Clearly there are some issues here that could be re-examined; but what is there now is certainly workable. --Carl Offner offner@hpc.pko.dec.com --------------------------------------------------------------------------- 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 Mar 25 10:48:13 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA14487 for hpff-interpret-out; Mon, 25 Mar 1996 10:48:13 -0600 (CST) Received: from cupid.cs.utk.edu (CUPID.CS.UTK.EDU [128.169.94.221]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id KAA14481 for ; Mon, 25 Mar 1996 10:48:09 -0600 (CST) From: rwhaley@cs.utk.edu Received: by cupid.cs.utk.edu (cf v2.11c-UTK) id LAA12813; Mon, 25 Mar 1996 11:48:05 -0500 Date: Mon, 25 Mar 1996 11:48:05 -0500 Message-Id: <199603251648.LAA12813@cupid.cs.utk.edu> To: hpff-interpret@cs.rice.edu, offner@hpc.pko.dec.com Subject: hpff-interpret: Re: Subject: Re: clarification for EXTRINSIC(HPF_LOCAL) Cc: rwhaley@cs.utk.edu, susan@cs.utk.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. --------------------------------------------------------------------------- Hi, >There is no constraint stopping an HPF_LOCAL routine from calling >a Fortran 77 routine, as far as I know. In fact, a standard way >of calling such routines would be, as you suggest, to use the HPF_LOCAL >routine as a wrapper to set up the argument passing for the Fortran 77 >or Fortran 90 routine it then calls. Such a routine could be >declared, for example, as EXTRINSIC(F90_LOCAL). (You have to declare >it as *something*; otherwise the default is that it is also considered >to be HPF_LOCAL.) > >Clearly there are some issues here that could be re-examined; but what >is there now is certainly workable. Thanks for the response, but this is not at all what I am asking. Probably my message was not very clear. If the compiler supports F90_LOCAL, I don't need the intermediary step of HPF_LOCAL in the first place. The whole point is that the compilers I have used are very selective in the extrinsics they support, and I'd like to be able to use HPF_LOCAL alone as a route to using an assumed size array. It is clear that if F90_LOCAL is supported, my problem is solved. However, if HPF_LOCAL is contrained to accept assumed shape arrays only when called from global HPF, I will have a solution if either F90_LOCAL or HPF_LOCAL is supported. It seems to me that the assumed shape restriction was probably set in place to facilitate transfer from the global HPF to local, and thus it is not necessary when one HPF_LOCAL routine calls another. Therefore, my question remains: can HPF_LOCAL routines which will not be called from global HPF take assumed size arrays? My original message is included below. Thanks, Clint Return-Path: Received: from cupid.cs.utk.edu (CUPID.CS.UTK.EDU [128.169.94.221]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id SAA25025; Fri, 22 Mar 1996 18:38:27 -0500 From: R Clint Whaley Received: by cupid.cs.utk.edu (cf v2.11c-UTK) id SAA06360; Fri, 22 Mar 1996 18:38:20 -0500 Date: Fri, 22 Mar 1996 18:38:20 -0500 Message-Id: <199603222338.SAA06360@cupid.cs.utk.edu> To: hpff-interpret@cs.rice.edu Subject: clarification for EXTRINSIC(HPF_LOCAL) Cc: rwhaley@cs.utk.edu, susan@cs.utk.edu Status: R Hi, I am looking at the HTML version of the HPF language specification, version 1.1. It says: >A dummy array argument of an EXTRINSIC(HPF_LOCAL) routine must have assumed >shape, even when it is explicit shape in the interface. Note that, in general, >the shape of a dummy array argument differs from the shape of the corresponding >actual argument, unless there is a single executing processor. I think this statement is misleading. Is it true that all HPF_LOCAL routines are constrained to accept only assumed shape arrays, or is it only HPF_LOCAL routines which are called from global HPF that have this restriction? The reason I ask is that we have Fortran77 code which we are hoping to access from HPF. The easiest route to do this is to have the HPF routine call an HPF_LOCAL routine with our arrays passed in as assumed shape. Then, since HPF_LOCAL is a superset of Fortran77, we declare our Fortran77 routine as another HPF_LOCAL routine taking an assumed size array (required by Fortran77). So, my question is: can HPF_LOCAL routines which will not be called from global HPF take assumed size arrays? If so, I think a slight rewording of the standard might help make this apparent. Thanks, Clint --------------------------------------------------------------------------- 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 Mar 25 11:53:01 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id LAA17223 for hpff-interpret-out; Mon, 25 Mar 1996 11:53:01 -0600 (CST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id LAA17214 for ; Mon, 25 Mar 1996 11:52:54 -0600 (CST) Received: from mpsg.hpc.pko.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA05502; Mon, 25 Mar 1996 12:36:30 -0500 Received: by mpsg.hpc.pko.dec.com; id AA03422; Mon, 25 Mar 1996 12:43:07 -0500 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 AA20410; Mon, 25 Mar 1996 12:36:28 -0500 Date: Mon, 25 Mar 1996 12:36:28 -0500 Message-Id: <9603251736.AA20410@hardy.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: Re: clarification for EXTRINSIC(HPF_LOCAL) Cc: offner@hpc.pko.dec.com, rwhaley@cs.utk.edu, susan@cs.utk.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. --------------------------------------------------------------------------- Perhaps you misunderstood what I was trying to say. You can take your Fortran 77 routine and call it from an HPF_LOCAL as you suggested. There is nothing that currently prevents you from doing that. The only thing you have to be careful about is that you have to explicitly declare it as NOT being HPF_LOCAL, since otherwise that is the default. I suggested EXTRINSIC(F90_LOCAL), which is compatible with Fortran 77. But anything else would do as well. --Carl Offner offner@hpc.pko.dec.com --------------------------------------------------------------------------- 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 Mar 25 12:37:40 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA18912 for hpff-interpret-out; Mon, 25 Mar 1996 12:37:40 -0600 (CST) Received: from cupid.cs.utk.edu (CUPID.CS.UTK.EDU [128.169.94.221]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id MAA18905 for ; Mon, 25 Mar 1996 12:37:32 -0600 (CST) From: rwhaley@cs.utk.edu Received: by cupid.cs.utk.edu (cf v2.11c-UTK) id NAA13059; Mon, 25 Mar 1996 13:37:31 -0500 Date: Mon, 25 Mar 1996 13:37:31 -0500 Message-Id: <199603251837.NAA13059@cupid.cs.utk.edu> To: hpff-interpret@cs.rice.edu, offner@hpc.pko.dec.com Subject: hpff-interpret: Re: clarification for EXTRINSIC(HPF_LOCAL) Cc: rwhaley@cs.utk.edu, susan@cs.utk.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. --------------------------------------------------------------------------- >Perhaps you misunderstood what I was trying to say. You can take >your Fortran 77 routine and call it from an HPF_LOCAL as you >suggested. There is nothing that currently prevents you from doing >that. The only thing you have to be careful about is that you >have to explicitly declare it as NOT being HPF_LOCAL, since otherwise >that is the default. I suggested EXTRINSIC(F90_LOCAL), which is >compatible with Fortran 77. But anything else would do as well. Yes, I understand your point. It was one I examined before sending mail. My whole problem is that I do not want to have to count on there being any extrinsic besides HPF_LOCAL. I see no reason to have the assumed shape restriction if one HPF_LOCAL routine calls another. If this is the case, I can call a Fortran77 routine using HPF_LOCAL as the only extrinsic type. To use the idea you are suggesting, the compiler must support two extrinsics, HPF_LOCAL and, for instance, F90_LOCAL or F77_LOCAL. To give you an example, DEC's HPF compiler (at least the version I have) supports only HPF and HPF_LOCAL. If the ruling is that HPF_LOCAL routines which are not called from global HPF can take assumed size arrays, I could get my code to work there without asking DEC to support more extrinsics. I believe that IBM's xlhpf also does not support F90_LOCAL or F77_LOCAL at this time. That is why my question involved the ruling on passing assumed size arrays between HPF_LOCAL routines, rather than how to call a F77 routine from HPF_LOCAL. Thanks, Clint --------------------------------------------------------------------------- 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 Mar 25 12:56:05 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA19787 for hpff-interpret-out; Mon, 25 Mar 1996 12:56:05 -0600 (CST) 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 MAA19780 for ; Mon, 25 Mar 1996 12:56:01 -0600 (CST) Received: from Custard.Think.COM by mail.think.com; Mon, 25 Mar 96 13:55:59 -0500 From: Carol Munroe Received: by custard.think.com (4.1/Think-1.2) id AA23119; Mon, 25 Mar 96 13:55:58 EST Date: Mon, 25 Mar 96 13:55:58 EST Message-Id: <9603251855.AA23119@custard.think.com> To: offner@hpc.pko.dec.com Cc: hpff-interpret@cs.rice.edu, offner@hpc.pko.dec.com, rwhaley@cs.utk.edu, susan@cs.utk.edu In-Reply-To: Carl Offner's message of Mon, 25 Mar 1996 12:36:28 -0500 <9603251736.AA20410@hardy.hpc.pko.dec.com> Subject: hpff-interpret: Re: clarification for EXTRINSIC(HPF_LOCAL) 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: offner@hpc.pko.dec.com (Carl Offner) Date: Mon, 25 Mar 1996 12:36:28 -0500 --------------------------------------------------------------------------- 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. --------------------------------------------------------------------------- Perhaps you misunderstood what I was trying to say. You can take your Fortran 77 routine and call it from an HPF_LOCAL as you suggested. There is nothing that currently prevents you from doing that. The only thing you have to be careful about is that you have to explicitly declare it as NOT being HPF_LOCAL, since otherwise that is the default. I suggested EXTRINSIC(F90_LOCAL), which is compatible with Fortran 77. But anything else would do as well. --Carl Offner offner@hpc.pko.dec.com Clint raised an important point that has been bothering me as well. Not all implementations of HPF_LOCAL necessarily have other types of EXTRINSIC interface available, so HPF_LOCAL should be complete in itself, especially since there exists a default assumption that a subprogram call from within an HPF_LOCAL routine is calling another HPF_LOCAL routine. I don't believe there was an intent to block any use of explicit shape arrays locally, whatever constraints might be put on dummies associated with globally distributed arrays (even such a constraint has disadvantages). I do believe that it should be possible to pass explicit-shape arrays from one HPF_LOCAL routine to another. I think the language specifications need to be altered to fix this problem. --Carol Munroe munroe@think.com --------------------------------------------------------------------------- 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 Mon Mar 25 13:35:14 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA21750 for hpff-interpret-out; Mon, 25 Mar 1996 13:35:14 -0600 (CST) Received: from moe.rice.edu (moe.rice.edu [128.42.5.4]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id NAA21737 for ; Mon, 25 Mar 1996 13:35:10 -0600 (CST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by moe.rice.edu (8.7.1/8.7.1) with SMTP id NAA24607 for ; Mon, 25 Mar 1996 13:13:15 -0600 (CST) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA25313; Mon, 25 Mar 1996 14:03:59 -0500 Received: by mpsg.hpc.pko.dec.com; id AA05054; Mon, 25 Mar 1996 14:10:36 -0500 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 AA20868; Mon, 25 Mar 1996 14:03:57 -0500 Date: Mon, 25 Mar 1996 14:03:57 -0500 Message-Id: <9603251903.AA20868@hardy.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: Re: clarification for EXTRINSIC(HPF_LOCAL) Cc: offner@hpc.pko.dec.com, rwhaley@cs.utk.edu, susan@cs.utk.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. --------------------------------------------------------------------------- Well, I agree that there may be some room for language development here. But we will soon be supporting F90_LOCAL for the very reason you need it; and the idea is that you can call it from an HPF_LOCAL as you desire. Calling an F90_LOCAL from a (global) HPF routine would still not be possible with anything but assumed-shape dummy arguments (unless some further language enhancements are made to support this kind of feature). I don't think this is a big feature for any compiler to implement -- the only real glitch is that the default for a routine called from HPF_LOCAL is stated to be HPF_LOCAL -- that's the only reason one even needs another kind of intrinsic at all in this case. --Carl Offner offner@hpc.pko.dec.com --------------------------------------------------------------------------- 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 Mar 25 13:38:12 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA21975 for hpff-interpret-out; Mon, 25 Mar 1996 13:38:12 -0600 (CST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id NAA21970 for ; Mon, 25 Mar 1996 13:38:08 -0600 (CST) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA30578; Mon, 25 Mar 1996 14:34:35 -0500 Received: by mpsg.hpc.pko.dec.com; id AA05633; Mon, 25 Mar 1996 14:41:13 -0500 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 AA21091; Mon, 25 Mar 1996 14:34:34 -0500 Date: Mon, 25 Mar 1996 14:34:34 -0500 Message-Id: <9603251934.AA21091@hardy.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: and yet again on HPF_LOCAL 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 guess what has been motivating my replies is the feeling that we are too late in this round of HPFF meetings to make any changes in HPF_LOCAL like what Clint is suggesting. Personally, I don't have any objection to having HPF_LOCAL be able to accept other than assumed-shape arguments when called from another HPF_LOCAL. I just thought that in effect we have a mechanism for doing that, with a very modest (really only a front-end) investment of work for a compiler, and that we were unlikely to get anything else immediately. Again, though, I agree that there is room here for some possible language change. --Carl Offner offner@hpc.pko.dec.com --------------------------------------------------------------------------- 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 Mar 28 03:57:03 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id DAA03336 for hpff-interpret-out; Thu, 28 Mar 1996 03:57:03 -0600 (CST) Received: from marin.ntnu.no (mari1.marina.unit.no [129.241.141.51]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id DAA03329 for ; Thu, 28 Mar 1996 03:56:51 -0600 (CST) Received: from klipper by marin.ntnu.no with SMTP id AA12953 (5.65/IDA-1.4.4); Thu, 28 Mar 1996 11:56:28 +0200 Received: by klipper.marina.unit.no (1.37.109.16/Uninett-C-1.4) id AA047167008; Thu, 28 Mar 1996 10:56:48 +0100 Date: Thu, 28 Mar 1996 10:56:48 +0100 Message-Id: <199603280956.AA047167008@klipper.marina.unit.no> From: Jens Helmers To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: 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. --------------------------------------------------------------------------- Is this a legal use of INDEPENDENT & NEW ??? REAL x, y(n) !HPF$ INDEPENDENT, NEW(i) DO i = 1, n x = x + y(i) ! Clumsy way to calculate: x=SUM(y) END DO Jens Helmers, jenhel@marin.unit.no --------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------