From owner-hpff-interpret Thu Jan 4 12:55:32 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA01195 for hpff-interpret-out; Thu, 4 Jan 1996 12:55:32 -0600 (CST) Received: from nrlmry.navy.mil (helium.nrlmry.navy.mil [192.138.87.243]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id MAA01189 for ; Thu, 4 Jan 1996 12:55:27 -0600 (CST) From: norton@nrlmry.navy.mil Received: from norton.nrlmry.navy.mil.nrlmry.navy.mil by nrlmry.navy.mil (4.1/SMI-4.1) id AA05961; Thu, 4 Jan 96 10:55:54 PST Received: by norton.nrlmry.navy.mil.nrlmry.navy.mil (SMI-8.6/SMI-SVR4) id KAA08020; Thu, 4 Jan 1996 10:54:07 -0800 Date: Thu, 4 Jan 1996 10:54:07 -0800 Message-Id: <199601041854.KAA08020@norton.nrlmry.navy.mil.nrlmry.navy.mil> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: Table lookups 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'm having a bit of trouble understanding how to do table lookups. Using some information from The Book, the only thing I have been able to come up with is to go to local space to do the actual lookup (under the requirement of only one table/processor): program foo real, dimension(137,NUMBER_OF_PROCESSORS) :: table real, dimension(1024,1024) :: AA, BB !HPF$ DISTRIBUTE (*,BLOCK(1)) :: table !HPF$ DISTRIBUTE (BLOCK,BLOCK) :: AA, BB interface EXTRINSIC(HPF_LOCAL) subroutine lookup (AA,BB,table) real, dimension(:,:), intent(INOUT) :: AA real, dimension(:,:), intent(IN) :: BB real, dimension(:,:), intent(IN) :: table !HPF$ DISTRIBUTE (:,:) :: AA,BB,table end subroutine lookup end interface data table/........./ call lookup (AA,BB,table) stop end EXTRINSIC(HPF_LOCAL) subroutine lookup (AA,BB,table) real, dimension(:,:), intent(INOUT) :: AA real, dimension(:,:), intent(IN) :: BB real, dimension(:,:), intent(IN) :: table !HPF$ DISTRIBUTE (:,:) :: AA,BB,table integer i,j,k !HPF$ INDEPENDENT do i=lbound(AA,1),ubound(AA,1) ! 1,ubound(AA,1) ! should be enough do j=lbound(AA,2), ubound(AA,2) do k=lbound(table,2),ubound(table,2) ! hopefully this == k=1,1 ! so it's just here ! for fun AA(i,j) = AA(i,j) + table(BB(i,j),k) enddo enddo enddo return end If this (or something close to this - I am temporarily without an HPF compiler) works, under HPF, great. However, I would really like to find out if there is a way to do the table lookups - one table/processor - that will also compile under F90 on a single CPU system. The above example has an HPF library function (NUMBER_OF_PROCESSORS) and the HPF EXTRINSIC syntax. What might be a nice solution to code this for both HPF and F90 (if it were legal syntax) would be something like: program foo integer i,j real, dimension(137) :: table ! I don't think this next statement is legal syntax ! but it would be nice if it were - treated as a comment under ! F90, but used under HPF. Yes - I could use something like the ! -dlines flag to a compiler or cpp, but that depends on the ! compiler, rather then the language !HPF$ real, dimension(137,NUMBER_OF_PROCESSORS) :: table_align real, dimension(1024,1024) :: AA, BB !HPF$ DISTRIBUTE (*,BLOCK(1)) :: table_align !HPF$ ALIGN table(i) WITH table_align(i,*) !HPF$ DISTRIBUTE (BLOCK,BLOCK) :: AA, BB ! sorry - I can't currently check if this would as intended !HPF$ INDEPENDENT do i=1,1024 do j=1,1024 AA(i,j) = AA(i,j) + table(BB(i,j)) enddo enddo ...... The short question then is - have I missed some other ways to do table lookups? thanks -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 --------------------------------------------------------------------------- From owner-hpff-interpret Thu Jan 4 16:49:17 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id QAA10544 for hpff-interpret-out; Thu, 4 Jan 1996 16:49:17 -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 QAA10521; Thu, 4 Jan 1996 16:49:13 -0600 (CST) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Jan 1996 16:48:53 -0600 To: norton@nrlmry.navy.mil From: chk@cs.rice.edu (Chuck Koelbel) Subject: hpff-interpret: Re: Table lookups 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 10:54 01/04/96, norton@nrlmry.navy.mil wrote: >I'm having a bit of trouble understanding how to do table lookups. >Using some information from The Book, the only thing I have been able >to come up with is to go to local space to do the actual lookup (under >the requirement of only one table/processor): Reading between a few lines, I think this is what you are trying to do: 1. Do many lookup operations in parallel. 2. Use the same (conceptual) table for all the lookups. (i.e. the table values are the same on all the lookups) 3. Store a copy of the conceptual table on all processors. 4. Have only one version of the code. So, I would suggest using ALIGN to replicate the table, and using a straight INDEPENDENT loop. Since the replication happens in ALIGN, the same code should work under both HPF and F90. I don't have an HPF compiler handy either, but the following should do it: real, dimension(1024,1024) :: AA, BB real, dimension(137) :: table !HPF$ DISTRIBUTE (BLOCK,BLOCK) :: AA, BB !HPF$ TEMPLATE dummy(NUMBER_OF_PROCESORS()) !HPF$ ALIGN table(i) WITH dummy(*) !HPF$ DISTRIBUTE dummy(BLOCK) !HPF$ INDEPENDENT do i=1,1024 do j=1,1024 AA(i,j) = AA(i,j) + table( truncate(BB(i,j)) ) enddo enddo I think your second syntax would also work, but this seems a bit simpler. A good compiler would even do the right thing (i.e. one copy per processor) if you said real, dimension(1024,1024) :: AA, BB real, dimension(137) :: table !HPF$ DISTRIBUTE (BLOCK,BLOCK) :: AA, BB !HPF$ ALIGN table(i) WITH AA(*,*) but it's possible that some compilers would create one copy per element of AA, definitely not the right thing to do. BTW, about >! sorry - I can't currently check if this would as intended >!HPF$ INDEPENDENT > do i=1,1024 > do j=1,1024 > AA(i,j) = AA(i,j) + table(BB(i,j)) > enddo > enddo The loop is definitely dependence-free, so it's correct to say INDEPENDENT. Most compilers ought to notice this on their own, but you never know. Whether your current compiler actually executes the INDEPENDENT loop in parallel is a different question - ask you vendor. >The short question then is - have I missed some other ways to do >table lookups? > >thanks >-dave This is really two questions: 1. Are there other ways to do the lookups in parallel? 2. Are there other ways to copy the lookup tables? In answer to 1., you could get the same effect with INDEPENDENT DO (see above) and FORALL (with or without an INDEPENDENT). This might or might not make a difference in how your compiler handles the program. The EXTRINSIC routine you started with works too (assuming all the details are right, I didn't check), but it seems like overkill- the lookups are data-parallel, so you'd expect that HPF can handle them well without resorting to extrinsics. In answer to 2., ALIGN is the basic way to get replication on all processors. Adding a NUMBER_OF_PROCESSORS dimension as you did works, but risks confusing the compiler (it has to realize which dimension is local). 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 Jan 5 04:38:42 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id EAA19801 for hpff-interpret-out; Fri, 5 Jan 1996 04:38:42 -0600 (CST) 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 ESMTP id EAA19795 for ; Fri, 5 Jan 1996 04:38:38 -0600 (CST) Received: from chad2-13.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Fri, 5 Jan 1996 10:37:44 +0000 From: "Dr A.C. Marshall" Message-Id: <199601051037.KAA05379@chad2-13.liv.ac.uk> Subject: Re: hpff-interpret: Table lookups To: norton@nrlmry.navy.mil Date: Fri, 5 Jan 1996 10:37:31 +0000 (GMT) Cc: hpff-interpret@cs.rice.edu (HPFF) In-Reply-To: <199601041854.KAA08020@norton.nrlmry.navy.mil.nrlmry.navy.mil> from "norton@nrlmry.navy.mil" at Jan 4, 96 10:54:07 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 norton@nrlmry.navy.mil said: | | |I'm having a bit of trouble understanding how to do table lookups. |Using some information from The Book, the only thing I have been able |to come up with is to go to local space to do the actual lookup (under |the requirement of only one table/processor): | | program foo | | real, dimension(137,NUMBER_OF_PROCESSORS) :: table | real, dimension(1024,1024) :: AA, BB | |!HPF$ DISTRIBUTE (*,BLOCK(1)) :: table |!HPF$ DISTRIBUTE (BLOCK,BLOCK) :: AA, BB | | interface | EXTRINSIC(HPF_LOCAL) subroutine lookup (AA,BB,table) | real, dimension(:,:), intent(INOUT) :: AA | real, dimension(:,:), intent(IN) :: BB | real, dimension(:,:), intent(IN) :: table |!HPF$ DISTRIBUTE (:,:) :: AA,BB,table | end subroutine lookup | end interface | | data table/........./ | | call lookup (AA,BB,table) | | stop | end | | EXTRINSIC(HPF_LOCAL) subroutine lookup (AA,BB,table) | | real, dimension(:,:), intent(INOUT) :: AA | real, dimension(:,:), intent(IN) :: BB | real, dimension(:,:), intent(IN) :: table |!HPF$ DISTRIBUTE (:,:) :: AA,BB,table | | integer i,j,k | |!HPF$ INDEPENDENT | do i=lbound(AA,1),ubound(AA,1) ! 1,ubound(AA,1) | ! should be enough | do j=lbound(AA,2), ubound(AA,2) | do k=lbound(table,2),ubound(table,2) ! hopefully this == k=1,1 | ! so it's just here | ! for fun | AA(i,j) = AA(i,j) + table(BB(i,j),k) | enddo | enddo | enddo | | return | end | |If this (or something close to this - I am temporarily without an HPF |compiler) works, under HPF, great. However, I would really like to |find out if there is a way to do the table lookups - one |table/processor - that will also compile under F90 on a single CPU |system. The above example has an HPF library function |(NUMBER_OF_PROCESSORS) and the HPF EXTRINSIC syntax. | |What might be a nice solution to code this for both HPF and F90 (if it |were legal syntax) would be something like: | | program foo | | integer i,j | real, dimension(137) :: table | |! I don't think this next statement is legal syntax |! but it would be nice if it were - treated as a comment under |! F90, but used under HPF. Yes - I could use something like the |! -dlines flag to a compiler or cpp, but that depends on the |! compiler, rather then the language Surely you could use a couple of cpp "#defines" for the F90 version; you could #define NUMBER_OF_PROCESSORS to be "1" and EXTRINSIC(HPF_LOCAL) to be a blank space (or no space at all). 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 | 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 Jan 15 18:48:09 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id SAA18453 for hpff-interpret-out; Mon, 15 Jan 1996 18:48:09 -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 SAA18439 for ; Mon, 15 Jan 1996 18:48:06 -0600 (CST) Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by moe.rice.edu (8.7.1/8.7.1) with ESMTP id SAA16037 for ; Mon, 15 Jan 1996 18:40:42 -0600 (CST) Received: from hplpp3.hpl.hp.com by hplms26.hpl.hp.com with ESMTP ($Revision: 1.36.108.11 $/15.5+ECS 3.3+HPL1.1S) id AA189672836; Mon, 15 Jan 1996 16:40:37 -0800 Received: by hplpp3.hpl.hp.com (1.37.109.14/15.5+ECS 3.3+HPL1.1) id AA094852840; Mon, 15 Jan 1996 16:40:40 -0800 Date: Mon, 15 Jan 1996 16:40:40 -0800 From: Rob Schreiber Message-Id: <199601160040.AA094852840@hplpp3.hpl.hp.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: allocate in pure 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. --------------------------------------------------------------------------- It appears that X3J3 has decided to allow allocate in PURE procedures, and it also seems that one cannot do some very simple things, like return the concatenation of two lists as the value of a pure function, without it. Shouldnt we conform with X3J3? The generic thing one wants to do (that is forbidden by the current HPF rule) is to allocate a linked structure and return a pointer to it as the result of a pure function. Rob Schreiber --------------------------------------------------------------------------- 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 Jan 15 18:49:50 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id SAA18646 for hpff-interpret-out; Mon, 15 Jan 1996 18:49:50 -0600 (CST) Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id SAA18625; Mon, 15 Jan 1996 18:49:38 -0600 (CST) Received: from hplpp3.hpl.hp.com by hplms26.hpl.hp.com with ESMTP ($Revision: 1.36.108.11 $/15.5+ECS 3.3+HPL1.1S) id AA190723376; Mon, 15 Jan 1996 16:49:37 -0800 Received: by hplpp3.hpl.hp.com (1.37.109.14/15.5+ECS 3.3+HPL1.1) id AA095263381; Mon, 15 Jan 1996 16:49:41 -0800 Date: Mon, 15 Jan 1996 16:49:41 -0800 From: Rob Schreiber Message-Id: <199601160049.AA095263381@hplpp3.hpl.hp.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: pointers, mapping etc Cc: hpff-distribute@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. --------------------------------------------------------------------------- There seems to be a lot of confusion about what mappings pointers can have. I hope the distribution group will tackle this and produce something we all understand and IBM will implement. The issues are these: 1. There seems to be no appetite anymore for any ambiguity as to mapping. That is why realign and redistribute and maybe inherit are on there way out. Thus, pointers that assume the mapping of their targets are viewed as bad. Since pointers must agree with their targets as to type and rank, the obvious solution is to give pointers mappings statically (at the declaration) and to require that the target have an identical mapping. This would apply to the allocated object if the pointer is used in an allocate. Why is this tricky? 1. What if the pointer and target have imprecise mappings, with something left to the compiler: real, pointer :: p(:,:) real x(100,100) !hpf$ distribute (block, block) :: x, p The compiler might choose different processors arrangements. 2. How do I generate and map linked structures one cell at a time? A reasonable HPF answer might be "Use some other programming language." 3. I dont see distribution ranges as the right answer here. In fact, with these rules and without dynamic mapping (and inherit?) there is no need for them. --------------------------------------------------------------------------- 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 Jan 16 03:37:38 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id DAA25131 for hpff-interpret-out; Tue, 16 Jan 1996 03:37:38 -0600 (CST) Received: from 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 DAA25125 for ; Tue, 16 Jan 1996 03:37:25 -0600 (CST) Date: Tue, 16 Jan 96 09:36:58 GMT Message-Id: <16733.9601160936@subnode.epcc.ed.ac.uk> To: schreibr@hplpp3.hpl.hp.com Subject: Re: hpff-interpret: allocate in pure 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. --------------------------------------------------------------------------- > It appears that X3J3 has decided to allow allocate in PURE procedures, and > it also seems that one cannot do some very simple things, like return > the concatenation of two lists as the value of a pure function, without > it. Shouldnt we conform with X3J3? > > The generic thing one wants to do (that is forbidden by the current > HPF rule) is to allocate a linked structure and return a pointer to it > as the result of a pure function. > > Rob Schreiber > --------------------------------------------------------------------------- I argued (without success) that the restriction on ALLOCATE was too strong a response to the CCI and that X3J3 would probably not accept it. Do they have a weaker restriction for the CCI in question? Unfortunately I can't seem to find a copy of the CCI. 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 Jan 16 11:23:37 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id LAA04603 for hpff-interpret-out; Tue, 16 Jan 1996 11:23:37 -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 LAA04598 for ; Tue, 16 Jan 1996 11:23:32 -0600 (CST) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8879; Tue, 16 Jan 96 12:22:39 EST Received: by TOROLAB (XAGENTA 4.0) id 1094; Tue, 16 Jan 1996 12:26:11 -0500 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA29232; Tue, 16 Jan 1996 12:23:16 -0500 From: (Henry Zongaro) Message-Id: <9601161723.AA29232@twinpeaks.torolab.ibm.com> Subject: hpff-interpret: Storage and sequence association To: hpff-interpret@cs.rice.edu (HPPF Interpretations) Date: Tue, 16 Jan 1996 12:23:13 -0500 (EST) Cc: cindy_chow@vnet.ibm.com 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, Consider the following program: program p !hpf$ sequence common /com/ a(10), b(10) !hpf$ nosequence /com/, b end program p According to section 7.1.4 of the HPF Language Spec., "a sequence directive with an empty association-name-list is treated as if it contained all implicitly mapped variables. . . which cannot otherwise be determined to be sequential or nonsequential by their language context." Should the fact that "a" appears in a nonsequential common block be sufficient to cause it to be passed over by the rule quoted above, which would mean that "a" would be nonsequential? Or, is it the case that since a nonsequential common block can contain both sequential and nonsequential data, the variable "a" cannot be determined to be sequential or nonsequential by its context in this example, and so it should be sequential because of the sequence directive? Any opinions? 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 Tue Jan 23 09:21:53 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA25556 for hpff-interpret-out; Tue, 23 Jan 1996 09:21:53 -0600 (CST) Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id JAA25450 for ; Tue, 23 Jan 1996 09:19:03 -0600 (CST) Received: from ry70.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Tue, 23 Jan 1996 16:17:54 +0100 Received: by ry70.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA090290258; Tue, 23 Jan 1996 16:17:38 +0100 Subject: hpff-interpret: EXTRINSIC comments/questions To: hpff-interpret@cs.rice.edu Date: Tue, 23 Jan 1996 16:17:38 +0100 (CET) Cc: sc22wg5-interop@ncsa.uiuc.edu From: hennecke@rz.uni-karlsruhe.de X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <"nz11.rz.un.280:23.01.96.15.18.09"@rz.uni-karlsruhe.de> 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, some questions and comments on EXTRINSIC are added below. I assembled them when collecting some material for the Fortran-C interoperability report of WG5. My general impression is that section 6 should be (a) sorted to put the v1.1 additions to more suitable places and (b) significantly shortened to only those aspects that do not depend on possible restrictions for s other than HPF. All such material should be collected in the annexes (A and B for the HPF_* keywords) to separate the general EXTRINSIC functionality from the specific implementations of the two interfaces defined within the HPF language. Regards, Michael Hennecke ====================================================================== Michael Hennecke http://www.uni-karlsruhe.de/~Michael.Hennecke/ ---------------------------------------------------------------------- University of Karlsruhe RFC822: hennecke@rz.uni-karlsruhe.de Computing Center (G20.21 R210) BITNET: RZ48@DKAUNI2.BITNET Zirkel 2 * P.O. Box 69 80 Phone: +49 721 608-4862 D-76128 Karlsruhe Fax: +49 721 32550 ====================================================================== HPF v1.1, section 6 143:14+ change "subprograms" to "procedures" SISAL and C extrinsics are not subprograms. 143:14+ Is a FORTRAN_LOCAL subprogram an HPF subprogram? 143:16.5 "It defines the means for handling distributed and replicated data at the interface." I do not see these definitions in section 6, which only imposes general restrictions on the callee in 6.3. IMHO, this is not in the scope of this section which only defines the caller's (declaration) part. Everything else is processor-dependent, except for the HPF_LOCAL and HPF_SERIAL specifications which are also not in section 6 but in annex A and B. 144:6.8 "should be declared EXTRINSIC ..." Is this a requirement or a recommendation? (Since HPF supports EXTERNAL, it probably cannot be a requirement.) If it is a recommendation, perhaps add more explanatory material like "Because HPF has to communicate some information about the distribution/alignment of procedure arguments, a user's assumptions about implementation details are more likely to fail as in sequential languages." 144:11 "6.2 Definition and Invocation ..." Change "Definition" to "Declaration". Except for the requirement that EXTRINSIC(HPF) is redundant and may appear in the definition of an HPF subprogram, this section is about declaring interfaces to EXTRINSIC procedures, not defining them. 144:26 Change "\bnf{extrinsic-kind}" to "\bnf{extrinsic-kind-keyword}" (alternatively, delete \bnf markup.) 144:29 Add a reference to annex B for HPF_SERIAL specifications: "The keyword HPF_SERIAL is intended for use in calling uniprocessor routines described in Annex B." 144:41.6 change "subprogram" to "procedure" (see 143:14+) 144:42.7 change "subprograms" to "procedures" (see 143:14+) 145:1+ The examples given implicitly require the C_LOCAL and SISAL languages to be able to pass arrays by descriptor because assumed shape arrays are passed to them. On 146+:43+, COBOL_LOCAL also recieves assued-shape arrays. This should be avoided. However: all argument passing becomes tricky if the EXTRINSIC is not Fortran... 145:9+ The OPERATOR(+) interface is not standard-conforming: add INTENT(IN) for X and Y. 145:32.8 "The intent is ... " Context lost... This should be a general requirement on EXTRINSIC, here it appears after the discussion of a generic interface example. 145:33.7 change "has been" to "had been" 146:2 "... mut have an explicit interface" Question 1: shoudn't this be "EXTRINSIC interface"? A mere interface block does not help, except for the default case. Question 2: Shouldn't this requirement be less strict? To my understanding, the only case where such an interface is always required is when the procedure arguments are distributed HPF arrays (or the Fortran standard requires one). 146:11 Move this stuff up to then beginning of 6.2. 146:28 "main-program" Change from \tt to \bnf markup 146:41 "... as the host scoping unit" (and the following example) There is no such thing: host association is restricted to internal and module subprograms, and derived type definitions (14.6.1.3). An interface block always has its own scope, it cannot access anything from outside by host association. Introducing such mechanisms in HPF seems to be very confusing. 147:38 change " ahs " to " has " HPF v1.1, annex A 162:8 Change "accessible to an extrinsic procedure (arrays passed as arguments)" to "passed as actual arguments to an extrinsic procedure", because there are more arrays accessible than array arguments: COMMON and MODULE objects. 164:4.5 "distributed HPF array" Does this include replicated arrays? If not, list them in the same lines as scalars. 165:3+ change \tt to \bnf markup three times 165:6 change "the the" to "the" 166:8.5 change "type" to "type and type parameters" 178:30 change "type" to "type and type parameters" --------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------