From owner-hpff-core Tue Apr 9 05:42:55 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id FAA00427 for hpff-core-out; Tue, 9 Apr 1996 05:42:55 -0500 (CDT) Received: from aloisius.vcpc.univie.ac.at (aloisius.vcpc.univie.ac.at [193.171.58.11]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id FAA00420 for ; Tue, 9 Apr 1996 05:42:48 -0500 (CDT) From: course@vcpc.univie.ac.at Received: from butthead.vcpc.univie.ac.at (butthead [193.171.58.39]) by aloisius.vcpc.univie.ac.at (8.7.5/8.7.3) with ESMTP id MAA02482 for ; Tue, 9 Apr 1996 12:39:27 +0200 (MET DST) Received: (from robinson@localhost) by butthead.vcpc.univie.ac.at (8.7.1/8.7.1) id MAA01149 for hpff-core@cs.rice.edu; Tue, 9 Apr 1996 12:43:15 +0200 (MET DST) Date: Tue, 9 Apr 1996 12:43:15 +0200 (MET DST) Message-Id: <199604091043.MAA01149@butthead.vcpc.univie.ac.at> X-Authentication-Warning: butthead.vcpc.univie.ac.at: robinson set sender to course@vcpc.univie.ac.at using -r To: hpff-core@cs.rice.edu Subject: hpff-core: HPF WORKSHOP AT HPCNE, FRIDAY APRIL 19, 1996 Sender: owner-hpff-core Precedence: bulk --------------------------------------------------------------------------- hpff-core@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- HPF WORKSHOP AT HPCNE, FRIDAY APRIL 19, 1996 0900 High Performance Fortran Overview Ken Kennedy, Rice University, USA 1000 Vendor Session Using current HPF tools for software development. Cliff Addison, N.A. Software, United Kingdom. Support for irregular problems in the ACE HPF compiler. Arthur Veen, ACE, Netherlands. PGIs strategy for providing HPF. Larry Meadows, The Portland Group, USA. 1100 Coffee break 1130 Session: User Experiences with HPF Experiences with HPF at CSR4. Carlo Nardone, CRS4, Italy. HPF port of an Ocean Simulation. Tor Sorevik, Parallab, Norway. HPF port of an industrial irregular CFD application. Philippe Devillers, VCPC, Austria. The ESPRIT project PHAROS: Open HPF Programming Environment. Karl Solchenbach, Pallas, Germany. 1230-1400 lunch 1400 Session: Development of HPF Additional language features for HPF from the PPPE project. Barbara Chapman, VCPC, Austria /Thomas Brandes, GMD, Germany Approved features and extensions of HPF version 2. Chuck Koelbel, Rice University, USA. Task parallelism in HPF. Jaspal Subhlok, CMU, USA. 15.30 Coffee break 1600 Panel Discussion. IS CURRENT HPF ENOUGH FOR INDUSTRIAL APPLICATIONS ? Chaired By Alok Choudhary, Syracuse University, USA. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-core-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-core Tue Apr 9 16:18:38 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id QAA22445 for hpff-core-out; Tue, 9 Apr 1996 16:18:38 -0500 (CDT) Received: from [128.42.1.241] (tanete.cs.rice.edu [128.42.1.241]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id QAA22438; Tue, 9 Apr 1996 16:18:33 -0500 (CDT) X-Sender: tlc@cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 2 (High) Date: Tue, 9 Apr 1996 16:18:06 -0500 To: hpff-core From: tlc@rice.edu (Theresa Chatman) Subject: hpff-core: Details for the May 1-3 HPFF meeting Cc: tlc, nnemer@mcs213k.cs.umr.edu, hatchell@cs.yale.edu, butler, jxyb@lanl.gov, kamratha@SDSC.EDU, boisseau@snowdog.sdsc.edu Sender: owner-hpff-core Precedence: bulk --------------------------------------------------------------------------- hpff-core@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- To the HPFF core group: The next HPFF meeting will be held on May 1-3, 1996. The meeting will be held at the Arlington Hilton, 2401 East Lamar Boulevard, Arlington, TX, 76006. The registration fee for this meeting will be $100, and will be collected on site. Please make your checks and POs payable to Rice University (no credit cards or cash, please). In order to adequately prepare for the meeting, I will need to know if you plan to attend, so please RSVP to tlc@rice.edu. If you are a vegetarian or have any other special needs, I will need to know this as well. To make your hotel reservations, call 817-640-3322 or 1-800-527-9332 by April 19, 1996 (the fax number is 817-633-1430). After that date, the rooms will be released to the general public. Be sure to refer to the HPFF meeting. Our sleeping room rate is $94 per night for single and double occupancy. The hotel sleeping rooms are equipped with dataport lines, so you will be able to use your portable computers from your sleeping rooms. The Arlington Hilton offers shuttle service to and from DFW Airport. In order to take advantage of this service, guests will need to call the Hilton from their courtesy phone in the baggage claim area. The cost of the service is $5 each way, and payment is taken upon boarding. This service is available from 7am to 11pm. The Hilton is 9 miles from the DFW airport (average time of travel is 10-15 minutes, dependent upon traffic). If you have handouts that you would like to have distributed at the HPFF meeting, please send them to me by noon Central Time on Monday, April 29, 1996. Electronic copies should be sent to tlc@rice.edu AND crpc.tr@cs.rice.edu. For the people who will be supported by the CRPC: when you make your hotel reservations, please present them with a credit card number in order to cover your incidentals. The CRPC will be directly billed for your sleeping room charges. The format of the meeting follows: Wednesday, 5/1 1pm - 10pm Three breakout rooms conference style for 10-15 people each. Coffee and sodas will be provided. Dinner is at your own expense. Thursday, 5/2 8:30am - 10pm One U-shaped room for 30 people. Two breakout rooms conference style for 10-15 people each. Continental breakfast and lunch will be provided. Dinner is at your own expense. At check in, you will be given two coupons to use for continental breakfast in Conrad's Restaurant. Note - these are to be used on Thursday and Friday mornings. Also note that the restaurant seems to start getting a lot of traffic at 8am, so you may want to try to get there before that time. Friday, 5/3 8:30am to noon One U-shaped room for 30 people. Continental breakfast will be provided. If you have any questions regarding the logistics for the HPFF meeting, please let me know. If you have any questions regarding technical issues, please direct them to Mary Zosel (zosel@llnl.gov). Also, for your information, our contact person at the Arlington Hilton is Juliann Sill. Sincerely, Theresa Chatman Manager of Outreach Programs, CRPC Rice University MS-41 6100 South Main Street Houston, TX 77005 713-285-5180 Phone 713-285-5136 Fax tlc@rice.edu --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-core-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-core Thu Apr 11 06:31:58 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id GAA25309 for hpff-core-out; Thu, 11 Apr 1996 06:31:58 -0500 (CDT) Received: from aloisius.vcpc.univie.ac.at (aloisius.vcpc.univie.ac.at [193.171.58.11]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id GAA25303 for ; Thu, 11 Apr 1996 06:31:48 -0500 (CDT) From: course@vcpc.univie.ac.at Received: from butthead.vcpc.univie.ac.at (butthead [193.171.58.39]) by aloisius.vcpc.univie.ac.at (8.7.5/8.7.3) with ESMTP id NAA03026 for ; Thu, 11 Apr 1996 13:28:38 +0200 (MET DST) Received: (from robinson@localhost) by butthead.vcpc.univie.ac.at (8.7.1/8.7.1) id NAA01094 for hpff-core@cs.rice.edu; Thu, 11 Apr 1996 13:32:29 +0200 (MET DST) Date: Thu, 11 Apr 1996 13:32:29 +0200 (MET DST) Message-Id: <199604111132.NAA01094@butthead.vcpc.univie.ac.at> X-Authentication-Warning: butthead.vcpc.univie.ac.at: robinson set sender to course@vcpc.univie.ac.at using -r To: hpff-core@cs.rice.edu Subject: hpff-core: HPF WORKSHOP AT VCPC July 1st-4th, 1996 Sender: owner-hpff-core Precedence: bulk --------------------------------------------------------------------------- hpff-core@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Announcement Summer of HPF in Vienna July 1-4, 1996, Vienna, Austria High Performance Fortran (HPF) is a data parallel language extension to Fortran90 which provides a portable programming interface for a wide variety of target platforms. The original HPF language specification was produced by the High Performance Fortran Forum, a broad consortium of industry and academia, which met regularly throughout 1992 and early 1993. HPF compilers are now available on most commonly-used computing systems, and users are beginning to gain first hand experience with this language. The HPF Forum began a second round of meetings in January 1995 with the aim of working on the features which could not be dealt with in the original specification, as well as support to the vendors implementing HPF. The results of this round are due for public review in a draft form during the summer of 1996. To increase public knowledge of HPF a workshop and a tutorial with a hands-on session will be held in Vienna during the first week of July, (1st-4th July). The complete agenda of events is described below. This workshop is organised by the Vienna Centre for Parallel Computing (VCPC) as part of the ESPRIT project HPC-Standards. July 1: Tutorial: HPF in practice July 2: Tutorial: Hands on session July 3/4: Workshop: HPF for real applications Participants may register for one or both of the above events using the form attached. The workshop will be held at hotel Austrotel, Felberstr. 4, A-1150 Vienna. Tutorial The tutorial is divided into two parts. Day One: HPF in Practice, Charles Koelbel, Rice University. This tutorial will introduce programmers to the most important features of HPF and illustrate how they can be used in practice for scientific computation. Further details can be found at http://www.cs.rice.edu/~chk/hpf-tutorial.html Day Two: HPF Tutorial, NA Software. Attendees will have hands on access to the NA Software HPF mapper and tools on the Meiko CS-2 at VCPC. Please note that there are a limited number of places for the `hands-on' sessions. Workshop In this workshop, we give an overview of the work of the HPF Forum, including its recent activities. A number of major compiler vendors will present their views on HPF and give an update on their efforts. There will also be contributions from several leading software houses who are beginning to port applications to HPF. Tools for HPF, and the use of HPF together with MPI will also be considered. The program will give ample time for both formal and informal discussion. Speakers for the workshop include the following; Presentations from researchers in HPF and members of the HPF Forum including Chuck Koelbel (Rice University/CRPC), Piyush Mehrotra (ICASE), Barbara Chapman (VCPC), Thomas Brandes (GMD), John Merlin (University of Southampton), Sigi Benkner (University of Vienna) and others. Descriptions of current and future compilers from a number of vendors including Larry Meadows (PGI), Manish Gupta (IBM), Harvey Richardson (TMC), Cliff Addison (NAS) and others. Summaries of experiences by `real' users from a range of industrial and research organisations, including Henk Sips (Amsterdam), Scott Baden (UCSD) and Guy Robinson (VCPC). Reports from the PHAROS ESPRIT project of the experiences of CISE, debis, MATRA and SEMCAP with current compilers and the conversion of real applications to HPF-1, and the HPF+ ESPRIT projects work in developing extensions to HPF-1 to reflect the complexity of advanced applications from AVL, ESI and ECMWF. Contact To register for the above events or to request further information please contact course@vcpc.univie.ac.at or http://www.vcpc.univie.ac.at or complete the form attached. ______________________ European Centre for Parallel Computing at Vienna, (VCPC) Liechtensteinstr. 22, A-1090 Vienna, Austria, Europe Tel: +43-1-3109396-10, Fax: +43-1-3109396-13, E-mail: info@vcpc.univie.ac.at Registration form European Centre for Parallel Computing at Vienna (VCPC) Summer of HPF July 1-4, 1996, Vienna, Austria Name: ________________________________________________________________________ Affiliation: _________________________________________________________________ Address: _____________________________________________________________________ _________________________________ Telephone: ________________________________ Fax: ____________________________ E-mail: ___________________________________ I wish to attend (please cross): o the HPF Tutorial on day one only (July 1) o the HPF Tutorial on both days (July 1/2) o the HPF Workshop on July 3/4 Please send me further information on: o the HPF Tutorial on day one only (July 1) o the HPF Tutorial on both days (July 1/2) o the HPF Workshop on July 3/4 o Please send me information on future workshops and tutorials o Please send me hotel information o Please book a room for me at hotel Austrotel, or a nearby hotel (please indicate preference). Type of room: o Single o Double Arrival date: ___________________ Departure date: ________________________ Date: ____________________________ Signature: ________________________________ Fees Payment should be enclosed if you register for the tutorial or the workshop. Please make cheques payable to VCPC. All payments must be in Austrian Schillings. Fees include refreshments and lunch on each day of the events for which you register. Day one only (July 1): Until May 20 After May 20 Academic, etc: 1700 ATS 2100 ATS Industry: 2300 ATS 2800 ATS Day one and two (July 1/2): Until May 20 After May 20 Academic, etc: 2300 ATS 2700 ATS Industry : 2850 ATS 3500 ATS Workshop (July 3/4): Until May 20 After May 20 Academic, etc: 1800 ATS 2200 ATS Industry : 2400 ATS 2800 ATS I qualify for the o Academic, project fee o Industry fee Name of project: _____________________________________________________________ Method of payment: o Enclosed Cheque o American Express o Eurocard/Mastercard o Visa o Diners Club Total amount of payment: _____________________________________________________ Credit Card Number: __________________________ Exp. date: ____________________ Cardholder Name: _____________________________________________________________ Date: ______________________________ Signature: ______________________________ _______________________ European Centre for Parallel Computing at Vienna, (VCPC) Liechtensteinstr. 22, A-1090 Vienna, Austria Tel: +43-1-3109396-10, Fax: +43-1-3109396-13, E-mail: info@vcpc.univie.ac.at --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-core-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-core Tue Apr 16 17:58:36 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id RAA11928 for hpff-core-out; Tue, 16 Apr 1996 17:24:35 -0500 (CDT) Received: from [128.42.1.241] (tanete.cs.rice.edu [128.42.1.241]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id RAA11903 for ; Tue, 16 Apr 1996 17:24:28 -0500 (CDT) X-Sender: tlc@cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) Date: Tue, 16 Apr 1996 17:23:55 -0500 To: hpff-core From: tlc@rice.edu (Theresa Chatman) Subject: hpff-core: DEADLINE April 19 - hotel reservations Sender: owner-hpff-core Precedence: bulk --------------------------------------------------------------------------- hpff-core@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Hello all, If you have not already done so, please be sure to make your hotel reservations for the May HPFF meeting ASAP. The cut-off date for hotel reservations is Friday, April 19. Thanks, Theresa >X-Sender: tlc@cs.rice.edu >Mime-Version: 1.0 >X-Priority: 2 (High) >Date: Tue, 9 Apr 1996 16:18:06 -0500 >To: hpff-core >From: tlc@rice.edu (Theresa Chatman) >Subject: Details for the May 1-3 HPFF meeting >Cc: tlc, nnemer@mcs213k.cs.umr.edu, hatchell@cs.yale.edu, butler, > jxyb@lanl.gov, kamratha@SDSC.EDU, boisseau@snowdog.sdsc.edu > >To the HPFF core group: > >The next HPFF meeting will be held on May 1-3, 1996. The meeting will >be held at the Arlington Hilton, 2401 East Lamar Boulevard, Arlington, TX, >76006. > >The registration fee for this meeting will be $100, and will be collected >on site. Please make your checks and POs payable to Rice University (no >credit cards or cash, please). In order to adequately prepare for the >meeting, I will need to know if you plan to attend, so please RSVP to >tlc@rice.edu. If you are a vegetarian or have any other special needs, I >will need to know this as well. > >To make your hotel reservations, call 817-640-3322 or 1-800-527-9332 >by April 19, 1996 (the fax number is 817-633-1430). After that date, the >rooms will be released to the general public. Be sure to refer to the HPFF >meeting. > >Our sleeping room rate is $94 per night for single and double occupancy. >The hotel sleeping rooms are equipped with dataport lines, so you will be >able to use your portable computers from your sleeping rooms. > >The Arlington Hilton offers shuttle service to and from DFW Airport. In >order to take advantage of this service, guests will need to call the >Hilton from their courtesy phone in the baggage claim area. The cost of >the service is $5 each way, and payment is taken upon boarding. This >service is available from 7am to 11pm. The Hilton is 9 miles from the DFW >airport (average time of travel is 10-15 minutes, dependent upon traffic). > >If you have handouts that you would like to have distributed at the HPFF >meeting, please send them to me by noon Central Time on Monday, April 29, >1996. Electronic copies should be sent to tlc@rice.edu AND >crpc.tr@cs.rice.edu. > >For the people who will be supported by the CRPC: when you make your hotel >reservations, please present them with a credit card number in order to >cover your incidentals. The CRPC will be directly billed for your sleeping >room charges. > >The format of the meeting follows: > >Wednesday, 5/1 > >1pm - 10pm > >Three breakout rooms conference style for 10-15 people each. > >Coffee and sodas will be provided. Dinner is at your own expense. > > >Thursday, 5/2 > >8:30am - 10pm > >One U-shaped room for 30 people. >Two breakout rooms conference style for 10-15 people each. > >Continental breakfast and lunch will be provided. Dinner is at your own >expense. At check in, you will be given two coupons to use for >continental breakfast in Conrad's Restaurant. Note - these are to be used >on Thursday and Friday mornings. Also note that the restaurant seems to >start getting a lot of traffic at 8am, so you may want to try to get there >before that time. > > >Friday, 5/3 > >8:30am to noon > >One U-shaped room for 30 people. > >Continental breakfast will be provided. > >If you have any questions regarding the logistics for the HPFF meeting, >please let me know. If you have any questions regarding technical issues, >please direct them to Mary Zosel (zosel@llnl.gov). > >Also, for your information, our contact person at the Arlington Hilton is >Juliann Sill. > >Sincerely, >Theresa Chatman >Manager of Outreach Programs, CRPC >Rice University >MS-41 >6100 South Main Street >Houston, TX 77005 >713-285-5180 Phone >713-285-5136 Fax >tlc@rice.edu > --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-core-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-core Fri Apr 26 12:06:50 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA26790 for hpff-core-out; Fri, 26 Apr 1996 12:06:50 -0500 (CDT) Message-Id: <199604261706.MAA26790@cs.rice.edu> Date: Fri, 26 Apr 1996 10:55:15 -0500 (CDT) From: Carol Munroe Cc: eugene@think.com, hamel@think.com Subject: hpff-core: HPFF proposal for an F77_LOCAL extrinsic interface Sender: owner-hpff-core Precedence: bulk --------------------------------------------------------------------------- hpff-core@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- The following is a proposal (prepared here at Thinking Machines) that I would like to have considered for next week's meeting. I apologize for presenting it at the last minute, especially since it may seem long, but the essence of the interface is described in the first few pages, while over half of it consists of examples and specifications for utility routines. When you look this over, please note that there is an important option left open concerning how descriptor information should be made available to local array inquiry routines, similar to the F90 array inquiry intrinsics and the HPF_LOCAL_LIBRARY ones, assuming that at least some such routines should be provided. The question is whether or not to have users pass descriptor handles explicitly, in light of possible ambiguities resulting from passing local array data by address only. The main method presented in this proposal hides the descriptors even when local inquiry functions are used, but an alternate method of passing them explicitly, when arrays will be used in inquiry functions, is also suggested in a highlighted paragraph on page four. I would appreciate feedback on this topic and on the proposal as a whole. the sooner the better, to have a sense of what HPFF members really want in this interface, since there are very few meetings remaining to present this in. ******cut here for f77_local.tex********************************************* \documentstyle[twoside,11pt]{article} \pagestyle{myheadings} \sloppy \footheight=-.60in \headheight=0in \textwidth=5.50in \topmargin=-.20in \oddsidemargin=0.5in \evensidemargin=0.5in \itemsep=.05in \topsep=.05in \parsep=.05in \parskip=.10in \textheight=9in \newcounter{dofigures} \setcounter{dofigures}{0} \newcounter{dotables} \setcounter{dotables}{0} \newcommand{\havefigures}{\setcounter{dofigures}{1}} \newcommand{\havetables} {\setcounter{dotables}{1}} \newcommand{\cccdocid}[5]{ \bibliographystyle{alpha} % ******************** Title Page ******************** \vspace*{.5in} \centerline{\Large \bf {#1}} \vspace*{.02in} \centerline{{#2}} \vspace*{.02in} \centerline{{#3}} \vspace*{.02in} \centerline{{#4}} \vspace*{.02in} \centerline{{#5}} \vspace*{.5in} % ******************** List of Figures ******************** % Note: Remove the following line if there are no figures % \ifodd\value{dofigures} \listoffigures \newpage \fi % \ifodd\value{dotables} \listoftables \newpage \fi % \markboth{#1} {#3} % \pagenumbering{arabic} } % ******************** Special macros ******************** %\catcode`^^Z=9 % Make TeX ignore IBMPC EOF character \newcommand{\ital}[1]{{\it #1}} \newcommand{\type}[1]{{\tt #1}} \newcommand{\bold}[1]{{\bf #1}} \newcommand{\dfn}[1]{{\it #1}\index{#1}} \newcommand{\comment}[1]{} \def\fineprint{\relax} \def\stopfine{\relax} \newcommand{\beginprog}{\begin{tabbing} xxxx\=xxxx\=xxxx\=xxxx\=xxxx\=xxxx\=xxxx\=xxxx\=xxxx\=xxxx\=\kill } \newcommand{\tb}{\>\tt} \newcommand{\finprog}{\end{tabbing}} \newcommand{\progtxt}[1]{``{\tt #1}''} \newcounter{save_enum} \newcommand{\hilite}[1]{ \item {\bf #1\\} } \newcommand{\morelater}{\centerline{$\ldots$\ital{Fill this in later}$\ldots$}} % ******************** Start of Document ******************** \begin{document} \cccdocid {EXTRINSIC(F77\_LOCAL) Interface} {Ver 1.1.2} {Eugene Loh} {Thinking Machines Corporation} {April, 1996} \begin{abstract} The legacy of FORTRAN~77 serial programming and the power and popularity of message-passing programming on parallel machines makes it incumbent on HPF to support a standard \type {EXTRINSIC(F77\_LOCAL)} interface. Here, an F77\_LOCAL interface is proposed. It preserves the basic nature of the HPF\_LOCAL interface but is also designed to be very straightforward for FORTRAN~77 programmers. \end{abstract} \section{Introduction} The HPF standard specifies the nature of \type {EXTRINSIC} interfaces in general and for HPF\_LOCAL in particular. Nevertheless, specification of an F77\_LOCAL interface poses challenges due chiefly to two differences between HPF and FORTRAN~77: \begin{itemize} \item Arguments are passed differently. In FORTRAN~77, arguments are typically passed between subprograms by address (reference). That is, no other information about the actual argument is passed --- for example, data type, size, distribution, etc. In contrast, HPF implementations often pass by descriptor in order to make such information available to the subprogram. \item Very different information about how array elements are to be assigned to specific memory locations is available to FORTRAN~77 and HPF programmers. In FORTRAN~77, the declaration of an array prescribes exactly the mapping of array elements to the linear sequence of storage locations. In HPF, the mapping of array elements to different processors may be controlled (e.g., with DISTRIBUTION and ALIGN directives) and queried (e.g., with HPF\_ALIGNMENT, HPF\_DISTRIBUTION, and HPF\_TEMPLATE) but there is absolutely no information about how array elements on a given processor are organized within local, serial memory. Indeed, different HPF compilers may organize the data locally in different manners --- perhaps including border cells for ``stencil'' optimizations, or global padding to ensure equal-size subgrids on all processors. Certainly, different HPF compilers are not \ital {bound} to organize local data in any particular manner, and some may choose imaginative orderings in such cases as SMP's, for example. \end{itemize} One could argue that there already exists a well-defined interface from HPF to F77\_LOCAL if the programmer goes through HPF\_LOCAL. Quite likely, this would involve SEQUENCE directives in the HPF\_LOCAL code. While the formal elegance of going to F77\_LOCAL only through HPF\_LOCAL is attractive, it is insufficient in several respects and it is certainly clumsy for FORTRAN~77 programmers. A direct F77\_LOCAL interface for global HPF is proposed here. Its characteristics include: \begin{itemize} \item Preservation of the basic nature of the HPF\_LOCAL interface. \item A simplified mechanism for calling local routines that eliminates much of the boilerplate code that is inherent to an HPF\_LOCAL approach. \end{itemize} The proposal is consistent with HPF's specification with regards to \type {EXTRINSIC} interfaces --- particularly, with regards to local procedures --- and is consistent with HPF\_LOCAL when appropriate. For example, before calling and upon returning from the \type {EXTRINSIC} routine, the HPF code should synchronize all processors. As necessary, the compiler should copy incorrectly mapped arguments to temporaries as indicated by INTERFACE blocks before invocation of and after return from an F77\_LOCAL subroutine, just as for any other extrinsic or non-extrinsic routine. Such remapping deals with what array elements are assigned to which processors. Local routines should not share names of COMMON blocks with global routines. A local routine should not have alternate returns. Any explicit message-passing calls within a local routine must be resolved before control is returned to the global caller. And so on. Otherwise, this proposal focuses on the differences between HPF\_LOCAL and this F77\_LOCAL interface. \section{PROPOSAL} This proposal may be presented in four parts: \begin{itemize} \item Argument passing. \item HPF-style utility subroutines. \item Subgrid-inquiry routine. \item Message-passing interface. \end{itemize} \subsection{Argument passing.} An argument is passed from HPF to an F77\_LOCAL routine by passing the base address of that section of local memory that has been allocated to it. If needed, an argument is first replicated to the processors. The restrictions in HPF\_LOCAL suffice to ensure that each physical processor contains a subset of array elements that can be locally arranged in a rectangular configuration. This rectangular configuration is reorganized in local, serial memory according to the \type {MAP\_TO} attribute specified for that argument in the \type {INTERFACE} block for the \type {EXTRINSIC(F77\_LOCAL)} routine: \begin{itemize} \item \type {MAP\_TO([LAYOUT=]F77\_ARRAY)} indicates that the rectangular configuration should be FORTRAN~77 sequence associated in local, serial memory. For example, many compilers add border elements for ``stencil'' optimizations or pad array allocations on particular processors so that all processors allocate equal amounts of memory for each array. Local reordering eliminates such padding and provides FORTRAN~77 sequence association for actual data values. Any local reordering is in addition to any global remapping that may be dictated by \type {DISTRIBUTION} or \type {ALIGN} directives in the \type {INTERFACE} block. If no \type {MAP\_TO()} attribute is specified, then \type {MAP\_TO(F77\_ARRAY)} is assumed. \item \type {MAP\_TO([LAYOUT=]NO\_CHANGE)} indicates that no local reordering of the data should occur. This option is desirable when the programmer decides that the overhead of local reordering should be eliminated or that certain characteristics of the global HPF compiler's ordering (border cells, equal-size allocations among processors, etc.) should be preserved at the local level. It forces the local programmer to access the local data in whatever implementation-dependent style the global HPF compiler employs. \end{itemize} [{\em {Note}}: The syntax of this attribute corresponds to that of Meltzer's ``HPF calling C Interoperability Proposal.'' It should be modified according to the fate of that proposal.] \subsection{HPF-style utility subroutines.} Of course, the global HPF caller may continue to call standard HPF array-inquiry routines and intrinsics. At the local level, FORTRAN~77 versions of particular HPF intrinsics and HPF\_LOCAL\_LIBRARY routines are supported. Since these routines must be called from FORTRAN~77 and not HPF, there are a couple of important distinctions. \begin{itemize} \item The prefix ``F77\_'' is prepended to the utility name. \item All arguments are required. None are optional. The effect of omitting an optional \type {DIM} or \type {PROC} argument may be attained by specifying a value of -1 for that argument. \item Arguments are FORTRAN~77 sequence associated. \item The utilities are subroutines --- none are functions. When the HPF analogs are functions, the F77\_ counterparts return values in a new argument that is prepended to the argument list. [{\em {Note}}: In great part, this distinction arises due to FORTRAN~77's inability to deal with array-valued functions. An important consequence, however, is that local programmers need not \type {INCLUDE} any header files or \type {USE} any modules since no functions, keywords, or interfaces need to be declared.] \item Arguments corresponding to global arrays should use the dummy argument passed in from the HPF caller. [{\em {Note to implementors}}: Note that the F77\_LOCAL routine accepts arrays passed by address rather than by descriptor. Hence, inquiry information is no longer directly available from the argument itself. [One implementation approach would be to construct a table of the descriptors for the arguments that are present in the argument list when the HPF program enters F77\_LOCAL mode, along with the corresponding base addresses that are actually passed to FORTRAN~77. A utility routine that is called from FORTRAN~77 could check this table for the base address and pick up the corresponding descriptor.] [{\bf Note: There is a question as to whether or not any ambiguities could arise. That is, perhaps two arguments in the call from HPF to F77\_LOCAL share the same base address but not the same descriptor --- perhaps because pointers are being used or because the HPF compiler passes certain array sections in-place. It may be necessary to document this restriction and note that an FORTRAN~77 subprogram assumes that distinct dummy arguments do not overlap in memory.} [{\bf These complications arise due to the need to provide programmers with inquiry routines at the local level without exposing implementation-dependent descriptors to them. An alternative is to have local programmers explicitly pass descriptors through to utility routines. For example, instead of the \type {MAP\_TO()} attribute, one might have \type {PASS(F77\_ARRAY)}, \type {PASS(NO\_CHANGE)}, and \type {PASS(DESCRIPTOR)}. The local routine would declare a descriptor object to be \type {INTEGER DESCRX(*)} and the local utility routines would expect such objects to be passed for global arrays. Though programmers would not be expected to manipulate descriptor objects directly, these descriptors would be exposed.} [{\bf Feedback on this point is welcome.}] \end{itemize} Otherwise, these routines should behave the same as their counterparts, without the ``F77\_'' prefaces, would in HPF\_LOCAL. The list of FORTRAN~77, locally supported, HPF-style routines is \begin{itemize} \item \type {F77\_GLOBAL\_ALIGNMENT}, \type {F77\_GLOBAL\_DISTRIBUTION}, \type {F77\_GLOBAL\_TEMPLATE} \item \type {F77\_ABSTRACT\_TO\_PHYSICAL}, \type {F77\_PHYSICAL\_TO\_ABSTRACT} \item \type {F77\_LOCAL\_TO\_GLOBAL}, \type {F77\_GLOBAL\_TO\_LOCAL} \item \type {F77\_LOCAL\_BLKCNT}, \type {F77\_LOCAL\_LINDEX}, \type {F77\_LOCAL\_UINDEX} \item \type {F77\_GLOBAL\_SHAPE}, \type {F77\_GLOBAL\_SIZE} \item \type {F77\_SHAPE}, \type {F77\_SIZE} \item \type {F77\_MY\_PROCESSOR} \end{itemize} [{\em {Note}}: There are no \type {F77\_GLOBAL\_\{L,U\}\_BOUND} routines since it is anticipated that \type {GLOBAL\_\{L,U\}\_BOUND} will be removed from the HPF\_LOCAL\_LIBRARY. Tied to their HPF\_LOCAL counterparts, routines such as \type {F77\_LOCAL\_TO\_GLOBAL} use one-based global indices.] \subsection{Subgrid-inquiry routine.} The HPF\_LOCAL style of programming is to determine bounds of the local portion of a distributed array within the local routine. This complicates indexing tremendously, particularly for multidimensional arrays, for two reasons: \begin{itemize} \item The programmer must perform the multidimensional indexing explicitly, instead of leaving this job to the FORTRAN~77 compiler. \item One must call utility subroutines and then construct global indices if global indices are of interest. \end{itemize} Thus, a globally callable subgrid-inquiry routine, which describes local subgrids in terms of global indices, is provided. There is also a locally callable version. These routines, \type {HPF\_SUBGRID\_INFO} and \type {F77\_SUBGRID\_INFO}, are described in a later section. Only the motivation is discussed here. Consider the HPF code \begin{verbatim} INTEGER X(NX,NY) !HPF$ DISTRIBUTE X(BLOCK,BLOCK) FORALL ( I=1:NX, J=1:NY ) X(I,J) = I + (J-1) * NX \end{verbatim} Writing this in FORTRAN~77 using an HPF\_LOCAL style, one might have \begin{verbatim} SUBROUTINE SUB( X ) REAL X(*) INTEGER L_INDEX(2), G_INDEX(2), L_SHAPE(2) ! DETERMINE NX CALL F77_GLOBAL_SIZE( NX , X , 1 ) ! GET LOCAL SHAPE CALL F77_SHAPE( L_SHAPE , X ) ! IDENTIFY OFFSET OF LOCAL DATA WITHIN GLOBAL ARRAY L_INDEX(1) = 1 L_INDEX(2) = 1 CALL F77_LOCAL_TO_GLOBAL( X , L_INDEX, G_INDEX) ! PERFORM OPERATION III = 0 DO J = 0, L_SHAPE(2) - 1 DO I = 0, L_SHAPE(1) - 1 III = III + 1 X(III) = (I + G_INDEX(1)) + (J + G_INDEX(2) - 1) * NX END DO END DO END \end{verbatim} In contrast, had the subgrid parameters in terms of global indices been passed in from the global caller, one might have written more easily and clearly \begin{verbatim} SUBROUTINE SUB( X , LB1 , UB1 , LB2 , UB2 ) INTEGER LB1 , UB1 , LB2 , UB2 REAL X( LB1:UB1 , LB2:UB2 ) ! DETERMINE NX CALL F77_GLOBAL_SIZE( NX , X , 1 ) ! PERFORM OPERATION DO J = LB2, UB2 DO I = LB1, UB1 X(I,J) = I + (J - 1) * NX END DO END DO END \end{verbatim} \subsection{Message-passing interface.} Many important, local subroutines will deal only with local data. Others, however, will require access to typical message-passing functionality. This proposal takes the approach of the HPF\_LOCAL specification, which is to claim that such communications ``are beyond the scope of this specification.'' This proposal also recommends that no ``generic interface'' to message-passing functionality from local subroutines be adopted by the HPFF. New calls would simply require HPFF to invent and users to learn ``yet another'' message-passing interface. This proposal also \ital {highly} recommends that HPF compiler providers support and F77\_LOCAL programmers use the MPI interface for message-passing calls. \section{SUBGRID INQUIRY} As mentioned above, a globally callable subgrid-inquiry routine, \type {HPF\_SUBGRID\_INFO}, which describes the local subgrids in terms of global indices, is provided. The routine is intended to simplify F77\_LOCAL programming in slightly restricted, but very common, cases. \subsection{``Embedding arrays''} First, a note on ``embedding arrays.'' In this proposal, the phrase ``embedding array'' refers to an array that is formed by taking a multidimensional, rectangular volume of data and extending it in each direction in each dimension (possibly by zero amounts). For example, the two-dimensional volume of data \begin{verbatim} A B C D E F G H I J K L \end{verbatim} may be embedded in any one of \begin{verbatim} * * * * * * * * A B C D A B C D * * A B C D * * E F G H E F G H * * E F G H * * I J K L I J K L * * I J K L * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * A B C D * A B C D * * * * E F G H * E F G H * * * * I J K L * I J K L * * * * * * * * * * * * * * \end{verbatim} While FORTRAN~77 compilers use sequence association to store rectangular volumes of data in serial memory, HPF compilers often embed local, rectangular subgrids in larger arrays and use sequence association for the larger, embedding arrays. The paddings are typically introduced to facilitate ``stencil'' optimizations or ensure equal-size memory allocations across the all processors. Whether due to user-specified alignments or variations among implementations regarding row-major versus column-major orderings, the axes of the embedding array may be ordered differently than those of the data volume. Thus, even if there were no extra padding, sequence association of the embedding array may lead to different storage of the data in serial memory than sequence association of the data volume would. \subsection{Restrictions} The description of local data provided by \type {HPF\_SUBGRID\_INFO} assumes a slightly restricted model over that chosen by HPF for local subprograms: \begin{itemize} \item Restriction 1. Mapping of elements among processors The first restriction is that the subset of array elements that is mapped to any processor must be expressible as an array section of the global array. This case includes most \type {*}, \type {BLOCK}, and \type {CYCLIC} distributions but precludes most \type {CYCLIC(N)} distributions as well as peculiar alignments. \item Restriction 2. Organization of elements on a given processor The second restriction is that the global compiler must store the local subgrid by extending it in each direction in each dimension (perhaps by zero amounts) and sequence associating the larger, ``embedding array.'' This restriction applies \ital {only} in the case that the \type {LB\_EMBED}, \type {UB\_EMBED}, or \type {AXIS\_MAP} arguments to \type {HPF\_SUBGRID\_INFO} are used. These arguments tell an F77\_LOCAL routine how a subgrid, passed from HPF with the \type {MAP\_TO(NO\_CHANGE)} attribute, is ordered by the global HPF compiler. In most cases, however, arrays will be passed to F77\_LOCAL subprograms with the default \type {MAP\_TO(F77\_ARRAY)} attribute so that \type {LB\_EMBED}, \type {UB\_EMBED}, and \type {AXIS\_MAP} will be of no interest and this second restriction will not apply. Instead, the local subgrid will be sequence associated in serial memory. All padding due to embedding will be removed. \end{itemize} If the local programmer does not use \type {HPF\_SUBGRID\_INFO} or \type {F77\_SUBGRID\_INFO}, then neither restriction applies at all. \subsection{HPF-callable subgrid-inquiry subroutine} The subgrid-inquiry subroutine is \type {HPF\_SUBGRID\_INFO (ARRAY, IERR, DIM, LB, UB, STRIDE, LB\_EMBED, UB\_EMBED, AXIS\_MAP)} \begin{itemize} \item \type {ARRAY} is an array of any type, size, shape, or distribution \item \type {IERR} is an error-status return variable, which is zero upon successful return and nonzero otherwise --- say, in the case that the appropriate restrictions are not satisfied \item \type {DIM} is an optional argument indicating the axis along which the parameters are desired --- if no axis is specified, parameters are returned for all axes \item \type {LB}, \type {UB}, \type {STRIDE} The remaining arguments are all optional, \type {INTENT (OUT)}, integer arrays. If a \type {DIM} argument is given, they are rank-one arrays of size \type {NUMBER\_OF\_PROCESSORS()} and \type {BLOCK} distribution. If no \type {DIM} argument is given, there is a second, collapsed axis whose extent is at least the rank of the global array. The arguments \type {LB}, \type {UB}, and \type {STRIDE} use indices of the global array to return the lower bounds, upper bounds, and strides of the array sections that describe the local subgrids. \item \type {LB\_EMBED}, \type {UB\_EMBED}, \type {AXIS\_MAP} These arguments are also optional arguments that should be declared like LB, UB, and STRIDE. They return the lower and upper bounds of the local embedding arrays using indices of the global array and the axes of the embedding array to which the axes of \type {ARRAY} are mapped. Thus, they are of interest only when the programmer will pass the array using the \type {MAP\_TO(NO\_CHANGE)} attribute. \end{itemize} [{\em {Note}}: It is unclear whether local programmers would prefer global indices to be one-based or to be however they declare them in the global caller. In any case, this proposal is predicated on and follows the convention established by HPF\_LOCAL that global indices should be one-based.] Consistent with the HPF model for local subprograms, it is assumed that array axes are mapped independently to axes of the rectangular processor grid. Thus, values for \type {LB}, \type {UB}, and \type {STRIDE} should be determined on an axis-by-axis basis. Results should be the same whether they are queried one-by-one, using a \type {DIM} argument, or all at once. In particular, if an axis does not have any index values mapped to a particular processor, then \type {UB = LB - STRIDE} on that processor for that axis. Values for other axes should be determined independently. If the array has no elements mapped to a particular processor, the choices for \type {UB\_EMBED}, \type {LB\_EMBED}, and \type {AXIS\_MAP} on that processor are somewhat arbitrary. There are certainly no guidelines within HPF --- in contrast to the situation for for \type {LB}, \type {UB}, and \type {STRIDE} --- since HPF only addresses which elements are mapped to which processors, but not how those elements are locally organized on a particular processor. The only strict requirement is that the values of \type {UB\_EMBED} and \type {LB\_EMBED}, given the value of \type {STRIDE}, should give the correct overall size of the locally allocated subgrid, even if none of its elements are actually used. It is suggested that \type {UB\_EMBED}, \type {LB\_EMBED}, and \type {AXIS\_MAP} continue to reflect the axis-by-axis mapping of the array to processors and if no memory is locally allocated due to a particular axis mapping, then \type {UB\_EMBED = LB\_EMBED - STRIDE} for that axis. \subsection{Example} Consider, for example, \begin{verbatim} REAL X(7,5) !HPF$ PROCESSORS P(2,2) !HPF$ DISTRIBUTE X(BLOCK,CYCLIC) ONTO P \end{verbatim} Then the subgrids on the various processors are X(1:4,1:5:2), X(5:7,1:5:2), X(1:4,2:4:2), and X(5:7,2:4:2). The subgrids can all written as array sections of the global array, fulfilling the first restriction. If one passed X to the programmer's F77\_LOCAL routine using the default \type {MAP\_TO(F77\_ARRAY)} attribute, one could call \type {HPF\_SUBGRID\_INFO} to describe the local, sequence-associated subgrids. If X were to be passed in to the programmer's F77\_LOCAL routine with the \type {MAP\_TO(NO\_CHANGE)} attribute, then \type {HPF\_SUBGRID\_INFO} could describe the local subgrids if the compiler used ``embedding arrays''. As examples, \begin{itemize} \item It may allocate only enough room for the subgrids --- in this case, 4x3, 3x3, 4x2, and 3x2 elements per processor, respectively. \item It may allocate same-sized subgrids on each processor. Then the data on each node is embedded in a larger array --- perhaps X(1:4,1:5:2), X(5:8,1:5:2), X(1:4,2:6:2), and X(5:8,2:6:2), respectively, or 4 x 3 elements per processor. \item It may also allocate extra border cells for ``stencil'' optimizations. The allocated arrays on the respective processors might be X(0:5,1:5:2), X(4:9,1:5:2), X(0:5,2:6:2), and X(4:9,2:6:2), or (1+4+1) x 3 elements per processor. \end{itemize} All of these allocations fulfill the second restriction so long as these larger embedding arrays are sequence associated in local, serial memory. For example, processor P(2,2) might have data values X(5:7,2:4:2) embedded in a storage array X(4:9,2:6:2) that is sequence associated in local, serial memory, leading the F77\_LOCAL routine to see \begin{verbatim} MAP_TO(NO_CHANGE) MAP_TO(F77_ARRAY) base address of X ----> * X(5,2) X(5,2) X(6,2) X(6,2) X(7,2) X(7,2) X(5,4) * X(6,4) * X(7,4) * * X(5,4) * X(6,4) * X(7,4) * * * * * * * * * * * * * * * * * \end{verbatim} \subsection{FORTRAN~77-callable subgrid-inquiry subroutine} The locally callable version of \type {HPF\_SUBGRID\_INFO} is \type {F77\_SUBGRID\_INFO (ARRAY, IERR1, IERR2, DIM, LB, UB, STRIDE, LB\_EMBED, UB\_EMBED, AXIS\_MAP)} \begin{itemize} \item all arguments are required --- none is optional \item \type {ARRAY} is a dummy argument passed in from global HPF \item \type {IERR1} is zero upon successful determination of \type {LB}, \type {UB}, and \type {STRIDE} and nonzero otherwise (e.g., subgrids are not expressible as array sections of the global array) \item \type {IERR2} is zero upon successful determination of \type {LB\_EMBED} and \type {UB\_EMBED} and nonzero otherwise (e.g., the global compiler does not organize data locally by sequence associating an ``embedding'' array) \item \type {DIM = -1} behaves the same as omitting the optional \type {DIM} argument in the global version \item the subgrid parameters \type {LB}, \type {UB}, \type {STRIDE}, \type {LB\_EMBED}, \type {UB\_EMBED}, and \type {AXIS\_MAP} should be declared as integer scalars if an axis is specified by the \type {DIM} argument or as rank-one integer arrays of size equal to at least the rank of the \type {ARRAY} if \type {DIM = -1} \end{itemize} \section{PROGRAMMING EXAMPLES} \subsection{\type {MAP\_TO(F77\_ARRAY)}} This example illustrates F77\_LOCAL programming using the default \type {MAP\_TO(F77\_ARRAY)} attribute. \subsubsection{HPF caller} \begin{verbatim} program example ! declare the data array and a verification copy integer, parameter :: nx = 100, ny = 100 real, dimension(nx,ny) :: x, y !hpf$ distribute(block,block) :: x, y ! the global sum will be computed ! by forming partial sums on the processors real partial_sum(number_of_processors()) !hpf$ distribute partial_sum(block) ! local subgrid parameters are declared per processor ! for a rank-two array integer, dimension(number_of_processors(),2) :: & lb, ub, number !hpf$ distribute(block,*) :: lb, ub, number ! define interfaces interface extrinsic(f77_local) subroutine local1 & ( lb1, ub1, lb2, ub2, x ) integer, dimension(:) :: lb1, ub1, lb2, ub2 real x(:,:) !hpf$ distribute(block) :: lb1, ub1, lb2, ub2 !hpf$ distribute(block,block) :: x end extrinsic(f77_local) subroutine local2(n,x,r) integer n(:) real x(:,:), r(:) !hpf$ distribute n(block) !hpf$ distribute x(block,block) !hpf$ distribute r(block) end end interface ! determine result using only global HPF ! initialize values forall (i=1:nx,j=1:ny) x(i,j) = i + (j-1) * nx ! determine and report global sum print *, 'global HPF result: ',sum(x) ! determine result using local subroutines ! initialize values ( assume stride = 1 ) call HPF_subgrid_info( y, ierr, lb=lb, ub=ub ) if (ierr.ne.0) stop 'error!' call local1( lb(:,1), ub(:,1), lb(:,2), ub(:,2), y ) ! determine and report global sum number = ub - lb + 1 call local2 ( number(:,1) * number(:,2) , y , partial_sum ) print *, 'F77_LOCAL result #1 : ',sum(partial_sum) end \end{verbatim} \subsubsection{FORTRAN~77 callee} \begin{verbatim} subroutine local1( lb1, ub1, lb2, ub2, x ) real x ( lb1 : ub1 , lb2 : ub2 ) ! get the global extent of the first axis ! this is an HPF_LOCAL type of inquiry routine with an ``F77_'' prefix call F77_global_size(nx,x,1) ! initialize elements of the array do j = lb2, ub2 do i = lb2, ub2 x(i,j) = i + (j-1) * nx end do end do end subroutine local2(n,x,r) ! here, the correspondence to the global indices is not important ! only the total size of the subgrid is passed in real x(n) r = 0. do i = 1, n r = r + x(i) end do end \end{verbatim} \subsection{\type {MAP\_TO(NO\_CHANGE)}} This example performs only the initialization of the above example. It illustrates use of the \type {MAP\_TO(NO\_CHANGE)} attribute and the addressing of data in terms of ``embedding arrays.'' \subsubsection{HPF caller} \begin{verbatim} program example integer, parameter :: nx = 100, ny = 100 real, dimension(nx,ny) :: y !hpf$ distribute(block,block) :: y ! local subgrid parameters are declared per processor ! for a rank-two array integer, dimension(number_of_processors(),2) :: & lb, ub, lb_embed, ub_embed !hpf$ distribute(block,*) :: lb, ub, lb_embed, ub_embed ! define interfaces interface extrinsic(f77_local) subroutine local1( & lb1, ub1, lb_embed1, ub_embed1, & lb2, ub2, lb_embed2, ub_embed2, x ) integer, dimension(:) :: & lb1, ub1, lb_embed1, ub_embed1, & lb2, ub2, lb_embed2, ub_embed2 real, dimension(:,:), map_to(no_change) :: x !hpf$ distribute(block) :: lb1, ub1, lb_embed1, ub_embed1 !hpf$ distribute(block) :: lb2, ub2, lb_embed2, ub_embed2 !hpf$ distribute(block,block) :: x end end interface ! initialize values ! ( assume stride = 1 and no axis permutation ) call HPF_subgrid_info( y, ierr, & lb=lb, lb_embed=lb_embed, & ub=ub, ub_embed=ub_embed) if (ierr.ne.0) stop 'error!' call local1( & lb(:,1), ub(:,1), lb_embed(:,1), ub_embed(:,1), & lb(:,2), ub(:,2), lb_embed(:,2), ub_embed(:,2), y ) end \end{verbatim} \subsubsection{FORTRAN~77 callee} \begin{verbatim} subroutine local1( & lb1, ub1, lb_embed1, ub_embed1, & lb2, ub2, lb_embed2, ub_embed2, x ) ! the subgrid has been passed in its "embedded" form real x ( lb_embed1 : ub_embed1 , lb_embed2 : ub_embed2 ) ! get the global extent of the first axis ! this is an HPF_LOCAL type of inquiry routine with an ``F77_'' prefix call F77_global_size(nx,x,1) ! otherwise, initialize elements of the array ! loop only over actual array elements do j = lb2, ub2 do i = lb2, ub2 x(i,j) = i + (j-1) * nx end do end do end \end{verbatim} \section{APPENDIX A. NEW HPF UTILITY SUBROUTINES} \subsection{ \type {HPF\_SUBGRID\_INFO (ARRAY, IERR, DIM, LB, UB, STRIDE, LB\_EMBED, UB\_EMBED, AXIS\_MAP)} } \begin{itemize} \item Description. Subgrid-inquiry subroutine. \item \type {ARRAY} is an array of any type, size, shape, or distribution. It is an \type {INTENT (IN)} argument. \item \type {IERR} is a scalar integer. It is an INTENT (OUT) argument. Its return value is zero upon successful return and nonzero otherwise. Errors result if local subgrids cannot be expressed as array sections of \type {ARRAY}. If LB\_EMBED, UB\_EMBED, or AXIS\_MAP is specified, then errors also result if the compiler does not organize the local data in serial memory by sequence associating a larger ``embedding'' array. \item \type {DIM} (optional) is a scalar integer. Is is an \type {INTENT (IN)} argument. \item \type {LB}, \type {UB}, \type {STRIDE}, \type {LB\_EMBED}, \type {UB\_EMBED}, \type {AXIS\_MAP} (all optional) are integer arrays. They are \type {INTENT (OUT)} arguments. If \type {DIM} is specified, they are rank-one arrays of size \type {NUMBER\_OF\_PROCESSORS()} and \type {BLOCK} distribution. If \type {DIM} is not specified, there is a second, collapsed axis whose extent is at least the rank of the global array. The return values are the lower and upper bounds and strides of the array sections describing the local data (in terms of global indices), the lower and upper bounds of the embedding arrays (again, in terms of global indices), and the axes of the embedding arrays to which the axes of \type {ARRAY} are mapped. \end{itemize} \section{APPENDIX B. NEW FORTRAN~77 UTILITY SUBROUTINES} In all of the following: \begin{itemize} \item \type {ARRAY} is some dummy argument passed in from the HPF caller corresponding to some global array or its local subgrid. It is an \type {INTENT (IN)} argument. \item \type {DIM} is a scalar integer. Is is an \type {INTENT (IN)} argument. This argument specifies a particular axis of the global array associated with \type {ARRAY} or, if \type {DIM = -1}, inquiry is for all axes. \item An ``inquiry result'' is an \type {INTENT (OUT)} argument. If \type {DIM = -1}, it is a rank-one array of size equal to at least the rank of the global array associated with \type {ARRAY}, returning information associated with all axes. If \type {DIM} is positive, the ``inquiry result'' is a scalar, returning information only for the axis indicated by \type {DIM}. \item The arguments are defined in the same way as for the corresponding HPF or HPF\_LOCAL routines unless otherwise noted. \end{itemize} \subsection{ \type {F77\_SUBGRID\_INFO (ARRAY, IERR1, IERR2, DIM, LB, UB, STRIDE, LB\_EMBED, UB\_EMBED, AXIS\_MAP)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF subroutine \type {HPF\_SUBGRID\_INFO}. \item \type {IERR1} is a scalar integer. It is an \type {INTENT (OUT)} argument. Its return value is zero if \type {LB}, \type {UB}, and \type {STRIDE} were determined successfully and nonzero otherwise. \item \type {IERR2} is a scalar integer. It is an \type {INTENT (OUT)} argument. Its return value is zero if \type {LB\_EMBED} and \type {UB\_EMBED} were determined successfully and nonzero otherwise. \item \type {LB}, \type {UB}, \type {STRIDE}, \type {LB\_EMBED}, \type {UB\_EMBED}, \type {AXIS\_MAP} are ``inquiry results'' of type integer. They are the lower and upper bounds and strides of the array sections describing the local data (in terms of global indices), the lower and upper bounds of the embedding arrays (again, in terms of global indices), and the axes of the embedding arrays to which the axes of \type {ARRAY} are mapped. \end{itemize} \subsection{ \type {F77\_GLOBAL\_ALIGNMENT (ALIGNEE, LB, UB, STRIDE, AXIS\_MAP, IDENTITY\_MAP, DYNAMIC, NCOPIES)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL subroutine \type {GLOBAL\_ALIGNMENT}. All but the first are \type {INTENT (OUT)} arguments whose return values are as specified by the corresponding HPF routine. \item \type {ALIGNEE} is a dummy argument passed in from global HPF. It is an \type {INTENT (IN)} argument. \item \type {LB}, \type {UB}, \type {STRIDE}, \type {AXIS\_MAP} are integer arrays of rank one. Their size must be at least equal to the rank of the global HPF array associated with \type {ALIGNEE}. \item \type {IDENTITY\_MAP}, \type {DYNAMIC} are scalar logicals. \item \type {NCOPIES} is a scalar integer. \end{itemize} \subsection{ \type {F77\_GLOBAL\_DISTRIBUTION (DISTRIBUTEE, AXIS\_TYPE, AXIS\_INFO, PROCESSORS\_RANK, PROCESSORS\_SHAPE)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL subroutine \type {GLOBAL\_DISTRIBUTION}. All but the first are \type {INTENT (OUT)} arguments whose return values are as specified by the corresponding HPF routine. \item \type {DISTRIBUTEE} is a dummy argument passed in from global HPF. It is an \type {INTENT (IN)} argument. \item \type {AXIS\_TYPE} is a \type {CHARACTER*9} array of rank one. Its size must be at least equal to the rank of the global HPF array associated with \type {DISTRIBUTEE}. \item \type {AXIS\_INFO} is an integer array of rank one. Its size must be at least equal to the rank of the global HPF array associated with \type {DISTRIBUTEE}. \item \type {PROCESSORS\_RANK} is an integer scalar. \item \type {PROCESSORS\_SHAPE} is an integer array of rank one. Its size must be at least equal to the value returned by \type {PROCESSORS\_RANK}. \end{itemize} \subsection{ \type {F77\_GLOBAL\_TEMPLATE (ALIGNEE, TEMPLATE\_RANK, LB, UB, AXIS\_TYPE, AXIS\_INFO, NUMBER\_ALIGNED, DYNAMIC)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL subroutine \type {GLOBAL\_TEMPLATE}. All but the first are \type {INTENT (OUT)} arguments whose return values are as specified by the corresponding HPF routine. \item \type {ALIGNEE} is a dummy argument passed in from global HPF. It is an \type {INTENT (IN)} argument. \item \type {TEMPLATE\_RANK} is a scalar integer. \item \type {LB}, \type {UB}, \type {AXIS\_INFO} are integer arrays of rank one. Their size must be at least equal to the rank of the align-target to which the global HPF array associated with \type {ALIGNEE} is ultimately aligned. \item \type {AXIS\_TYPE} is a \type {CHARACTER*10} array of rank one. Its size must be at least equal to the rank of the align-target to which the global HPF array associated with \type {ALIGNEE} is ultimately aligned. \item \type {NUMBER\_ALIGNED} is a scalar integer. \item \type {DYNAMIC} is a scalar logical. \end{itemize} \subsection{ \type {F77\_ABSTRACT\_TO\_PHYSICAL(ARRAY, INDEX, PROC)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL subroutine \type {ABSTRACT\_TO\_PHYSICAL}. \item \type {INDEX} is a rank-one, \type {INTENT (IN)}, integer array. \item \type {PROC} is a scalar, \type {INTENT (OUT)}, integer. \end{itemize} \subsection{ \type {F77\_PHYSICAL\_TO\_ABSTRACT(ARRAY, PROC, INDEX)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL subroutine \type {PHYSICAL\_TO\_ABSTRACT}. \item \type {PROC} is a scalar, \type {INTENT (IN)}, integer. \item \type {INDEX} is a rank-one, \type {INTENT (OUT)}, integer array. \end{itemize} \subsection{ \type {F77\_LOCAL\_TO\_GLOBAL(ARRAY, L\_INDEX, G\_INDEX)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL subroutine \type {LOCAL\_TO\_GLOBAL}. \item \type {L\_INDEX} is a rank-one, \type {INTENT (IN)}, integer array. \item \type {G\_INDEX} is a rank-one, \type {INTENT (OUT)}, integer array. \end{itemize} \subsection{ \type {F77\_GLOBAL\_TO\_LOCAL(ARRAY, G\_INDEX, L\_INDEX, LOCAL, NCOPIES, PROCS)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL subroutine \type {GLOBAL\_TO\_LOCAL}. \item \type {G\_INDEX} is a rank-one, \type {INTENT (IN)}, integer array. \item \type {L\_INDEX} is a rank-one, \type {INTENT (OUT)}, integer array. \item \type {LOCAL} is a scalar, \type {INTENT (OUT)}, logical. \item \type {NCOPIES} is a scalar, \type {INTENT (OUT)}, integer. \item \type {PROCS} is a rank-one, integer array whose size is at least the number of processors that hold copies of the identified element. \end{itemize} \subsection{ \type {F77\_LOCAL\_BLKCNT(L\_BLKCNT, ARRAY, DIM, PROC)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL function \type {LOCAL\_BLKCNT}. \item \type {L\_BLKCNT} is an ``inquiry result'' of type integer. \item \type {PROC} is a scalar integer. It must be a valid processor number or, if \type {PROC = -1}, the value returned by \type {F77\_MY\_PROCESSOR()} is implied. \end{itemize} \subsection{ \type {F77\_LOCAL\_LINDEX(L\_LINDEX, ARRAY, DIM, PROC)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL function \type {LOCAL\_LINDEX}. \item \type {L\_LINDEX} is a rank-one, integer array of size equal to at least the value returned by \type {F77\_LOCAL\_BLKCNT()}. \item \type {DIM} may not be -1. \item \type {PROC} is a scalar integer. It must be a valid processor number or, if \type {PROC = -1}, the value returned by \type {F77\_MY\_PROCESSOR()} is implied. \end{itemize} \subsection{ \type {F77\_LOCAL\_UINDEX(L\_UINDEX, ARRAY, DIM, PROC)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL function \type {LOCAL\_UINDEX}. \item \type {L\_UINDEX} is a rank-one, integer array of size equal to at least the value returned by \type {F77\_LOCAL\_BLKCNT()}. \item \type {DIM} may not be -1. \item \type {PROC} is a scalar integer. It must be a valid processor number or, if \type {PROC = -1}, the value returned by \type {F77\_MY\_PROCESSOR()} is implied. \end{itemize} \subsection{ \type {F77\_GLOBAL\_SHAPE(SHAPE, ARRAY)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL function \type {GLOBAL\_SHAPE}. \item \type {SHAPE} is a rank-one, integer array of size equal to at least the rank of the global array associated with \type {ARRAY}. Its return value is the shape of that global array. \end{itemize} \subsection{ \type {F77\_GLOBAL\_SIZE(SIZE, ARRAY, DIM)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL function \type {GLOBAL\_SIZE}. \item \type {SIZE} is a scalar integer equal to the extent of axis \type {DIM} of the global array associated with \type {ARRAY} or, if \type {DIM = -1}, the total number of elements in that global array. \end{itemize} \subsection{ \type {F77\_SHAPE(SHAPE, ARRAY)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF intrinsic \type {SHAPE()}, as it would behave as called from HPF\_LOCAL. \item \type {SHAPE} is a rank-one, integer array of size equal to at least the rank of the subgrid associated with \type {ARRAY}. Its return value is the shape of that subgrid. \end{itemize} \subsection{ \type {F77\_SIZE(SIZE, ARRAY, DIM)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF intrinsic \type {SIZE()}, as it would behave as called from HPF\_LOCAL. \item \type {SIZE} is a scalar integer equal to the extent of axis \type {DIM} of the subgrid associated with \type {ARRAY} or, if \type {DIM = -1}, the total number of elements in that subgrid. \end{itemize} \subsection{ \type {F77\_MY\_PROCESSOR(MY\_PROC)} } \begin{itemize} \item Description. FORTRAN~77-callable version of HPF\_LOCAL function \type {MY\_PROCESSOR}. \item \type {MY\_PROC} is a scalar, \type {INTENT (OUT)}, integer. Its value is the identifying number of the physical processor from which this call is made. \end{itemize} \end{document} --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-core-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-core Mon Apr 29 12:05:04 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA21516 for hpff-core-out; Mon, 29 Apr 1996 12:05:04 -0500 (CDT) Received: from coral.llnl.gov (coral.llnl.gov [134.9.1.2]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id MAA21503 for ; Mon, 29 Apr 1996 12:04:59 -0500 (CDT) Message-Id: <199604291704.MAA21503@cs.rice.edu> Received: by coral.llnl.gov (1.40.112.4/16.2) id AA231817497; Mon, 29 Apr 1996 10:04:57 -0700 Date: Mon, 29 Apr 1996 10:04:57 -0700 From: Mary E Zosel To: hpff-core@cs.rice.edu Subject: hpff-core: May Proposal Status Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-hpff-core Precedence: bulk --------------------------------------------------------------------------- hpff-core@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- To: HPFF-Core According to my records - the following is the status of proposals for the May HPFF meeting. -mz- ======= PROPOSAL STATUS 1st 2nd group C on Jan May ck task Mar May inq updates Jan May rs group D ptrs/dark corners Mar. May group E (SPMD-HPF-ext.) Mar May/June am/lfm Extrinsic rules Mar May No GLOBAL_LB/UB Mar May mz Sort functions Mar May cm F77_Local May June cm DONE - (C) async ext lm (C) gen transpose ext rs (D) reduc - simple 2 rs (D) reduc - simple amended 2 rs (D) derived typ ext gls (D) derived type amended ext (D) shadow width ext co (D) irreg map ext ? (D) dist ranges hz (D) seq. nonmap 2 cm (D) subsets ext pm (E) name/etc. (E) kernel chapter am (E) interop ext am (E) local_global func ? cm (E) explicit interf 2 ~ --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-core-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-core Mon Apr 29 14:23:57 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id OAA28720 for hpff-core-out; Mon, 29 Apr 1996 14:23:57 -0500 (CDT) Date: Mon, 29 Apr 1996 14:23:57 -0500 (CDT) From: owner-hpff-core Message-Id: <199604291923.OAA28720@cs.rice.edu> >From: Mary E Zosel Subject: hpff-core: HPFF May96 Active CCI Following are the active CCI items for the May HPFF meeting. For your reference - this long text file is ordered by group and contains the following: Sender: owner-hpff-core Precedence: bulk --------------------------------------------------------------------------- hpff-core@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- One CCI #58 for Group C - new One CCI #56 for either Group C or D - new Five CCI's for group D (11,39,47 ptr group), 49, 50 {both maybe done} Six CCI's for group E (45/46 pair) (51,54,55 group), 57 new -------- CCI #58 use of independent and new Group C Helmers jenhel@marin.unit.no submitted: 3/28/96 status: new question: 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 --- discussion: Answer from Henry Hi Jens, This is not a legal use of INDEPENDENT, unless n <= 1. When the INDEPENDENT directive appears before a DO, it asserts to the compiler that (among other things) two iterations of the DO will not assign to the same atomic object. Here, the assignment to x violates that condition, unless n is less than or equal to 1. A proposal that will appear in the HPF 2.0 document will permit some DO loops which perform intrinsic reduction operations to be marked as INDEPENDENT, like so: REAL x, y(n) x = 0.0 !HPF$ INDEPENDENT, NEW(i), REDUCTION(x) DO i = 1, n x = x + y(i) END DO Thanks, Henry __________________________________________________ CC I #56 Interpretation of HPF_TEMPLATE library routine Group C or D Whaley rwhaley@c.utk.edu submitted: 3/20/96 status: new question: 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 __________________________________________________ CCI #11 pointer with sequence Group D updated: 8/14/95 Henry Zongaro zongaro@VNET.IBM.COM submitted: 02/16/95 status: in progress Note - this one was marked resolved and then revived to be discussed together with 39 and 47 ... Current proposal (with strawvotes) follows this question. question: Hello, Things have been quiet here lately, so I thought I'd send a few questions that I've been hoarding. All page and line references are relative to the 1.0 HPF Language Spec. I'd like to hear other people's opinions on these, especially the 2nd and 3rd items. 1) The response to CCI item 6.3 indicated that variables with the POINTER attribute must be distributed or aligned. A related question - can they be given the SEQUENCE attribute? Or can a pointer be associated with both sequential and nonsequential targets? ===================================== PROPOSAL FROM THE MARCH 96 MEETING - ADDRESSING THIS CCI AND #39 and #47 11, 39, 47 - pointers. HPF 1.1. has contradictory statements about pointers. Proposal: 1st reading .... - Retain text in section 3.6 page 38 line 33 which states that pointers may appear as an alignee or a distributee - takes effect on allocation -delete constraints 3 page 27 line 5 - distribute cannot have pointer attribute (also page 186 line 48) - Add text: If a pointer (target) is explicitly mapped and is associated with a target using a pointer assignment, the mapping of the target object must MATCH the declared mapping of the pointer. (Where MATCH needs to be defined.) Override - then this applies only on allocation If a pointer is declared to be DYNAMIC, it can point to any non-sequential object. The RANGE directive can be used to restrict the mappings of the target object or the allocated array. A pointer declared sequential using the SEQUENCE attribute can point to sequential objects only. A pointer which is not explicitly mapped or declared sequential can point to a target which is not explicitly mapped or declared sequential. Discussion of DYNAMIC - is this an appropriate overloading of DYNAMIC? Can a dynamic pointer point to a static objects? PM - saying this is illegal is too restrictive --- but user might think that because pointer is dynamic it can be redistributed ... but other text should restrict this. example A(100), B(100) !HPF$ distribute (cyclic):: A,B pointer, dynamic :: p(;) p => A p=> B Straw poll on this for a first reading - clearly not ready for second reading 19 - 0 - 0. ======== previous discussions ... from July meeting - subgroup proposal: conforming dimensions of the pointer object and target either must be (unmapped or both be identcally distributed) or both must be sequential. The issue is ... does the pointer exist as an instance by itself, or is it just assocated with its bound arg. There is a case of pointers to sections of arrays, so just knowing that a pointer goes a block distributed thing, one can't talk about pointers to section.Andy Meltzer recalls that was related to the fact that allocatable objects don't have their distribution until after they are assigned. A straw poll was taken with special understanding that a substantial vote for "abstain" would mean reconsider. The vote was 7-3-10, so this CCI item is returned to committee for further clarification of the issue. ========= from September meeting minutes: CCI 11 Pointers cannot be mapped. Can they be associated with both sequential and non sequential targets? Subgroup recommends that pointers cannot point to sequential variables. Full group didn't think this was right and asked the subgroup to try again. ===== new proposal at Nov meeting: (a) Pointers with the HPF SEQUENCE attribute may point only to targets with the SEQENCE attribute. (b) POINTERS without the SEQUENCE attribute may point only to targets without the SEQUENCE attribute. When a pointer is invoked you know ahead whether it is sequence or not ... institutional vote ... 22 - 0 - 0 ====== -page 38 section 3.6 implies pointer can be mapped. This should specifically say that the pointer is not distributed, the pointee is. - pointers cannot be mapped End of 3.6 "for the relationship of pointers and sequence attricutes [ refernce to the next sentece] Add section 7.3 "Pointers and Sequence Association" - put rules (a) and (b) in the text ... ========== This was revisited at the March meeting --- see #39 and #47. A proposal is in progress addressing all three of these cci's. __________________________________________________ CCI #39 Mapping Pointer Restrictions Group D updated: 4/27/96 Larry Meadows lfm@pgroup.com submitted: 11/21/95 status: in progress - being discussed with #11 and #47 - see #11 for current proposals .. --- question: I've noticed an inconsistency in the 1.1 document wrt F90 pointers. You'll recall CCI 6.3, from last year; this resulted in additional constraints to the 1.1 document, that alignees and distributees could not have the POINTER target (p. 27, line 5, and p. 32, line 5). However, later in the same chapter, there is some text (p. 38, line 33): A variable with the POINTER or ALLOCATABLE attribute may appear as an alignee in an ALIGN directive or as a distributee in a DISTRIBUTE directive. This is clearly a contradiction. This is also somewhat related to CCI #11 (what is the SEQUENCE attribute when associated with a pointer). I'm assuming the following, in HPF 1.1: 1) Mapping statements can't apply to pointers. Note, therefore, that allocated pointers cannot be explicitly mapped. 2) Pointers can point to any object, regardless of their mapping attributes. For HPF 2.0, there was some restriction on pointers that I've forgotten. It really seems that a restriction similar to the following would be in the spirit of Kernel HPF: Mapping statements can be applied to pointers. These statements assert that any object with which the pointer is associated will have the described. Pointers with mapping statements may point only to whole arrays, not to subarrays. Pointers without mapping statements may point only to objects without explicit mappings, and may point to subarrays of those objects. lfm ------- ed note: this has both a cci item for group D and kernel input for group E... but is primarily a group D item. SEE #11 FOR CONTINUED DISCUSSION OF THIS ONE --- 11 and 39 and 47 are being discussed together. __________________________________________________ CCI #47 distribute/pointer contradiction Group D updated: 4/27/96 Singleton David.Singleton@anu.edu.au submitted: 2/2/96 status: in progress - being discussed with #11 and #39 - see #11 for current proposal ---- question: Is there a contradiction within the HPF 1.1 Language Specification document with regards to distributed pointer arrays? In section 3.3, page 27, line 5 (repeated in appendix C, page 186, line 48), it is stated that a distributee in a DISTRIBUTE directive may NOT have the POINTER attribute. However section 3.6, page 38, line 24, makes the contrary statement. The rest of section 3.6 clearly suggests that pointer arrays are supposed to be distributable. The negative statements where not in HPF Version 1.0. Can you clarify please? Thanks, David Singleton ----------- follow-up question after Henry's first reply ... Thanks for your prompt reply Henry. It is reasonable that a pointer array has the distribution of its associated target. However this does not cover the case when the pointer array is allocated instead of pointer assigned to an existing array. If pointers are removed from section 3.6 then the only conclusion is that pointer arrays cannot be allocated as distributed arrays. Is this correct? If true, this seems highly and unnecessarily restrictive. If allocatable and automatic arrays can be distributed, why not dynamically allocated pointer arrays? The big advantage of allocated pointer arrays is that they can be placed in the global namespace via COMMON or modules. The Fortran90 and HPF constraints on nonsequential COMMON blocks should be sufficient to include distributed pointer arrays. Not allowing pointer arrays as distributees or alignees also eliminates the possibility of REDISTRIBUTING or REALIGNING them after allocation as well. Even without having pointer arrays, CMFortran successfully encompassed dynamic allocation of distributed arrays albeit by actually giving the user access to array descriptors. Fortran90 pointer arrays should only simplify the user interface to such dynamic allocation. I would be very interested to understand the HPFF stance on allocated distributed pointer arrays - it doesn't appear to be addressed in HPF2 documents. If you can point me at any other relevant online documents, I'd be wery appreciative. Thanks for your help and time, discussion: NOTE THIS IS BEING ADDRESSED TOGETHER WITH #11 and #39 SEE TEXT IN #11 for the discussion from the March Meeting Answer from Henry Hi David, > Is there a contradiction within the HPF 1.1 Language Specification ... > suggests that pointer arrays are supposed to be distributable. Yes, there is a contradiction in the HPF 1.1 document. The response to an interpretation question posed was that pointers cannot appear as distributees in a DISTRIBUTE directive. Instead, a pointer acquires the mapping of its associated target, if any. The instance you cite in section 3.6 was missed in the HPF 1.1 document, but will be fixed in HPF 1.2. Thanks, Henry ----- followup reponse from Henry after second question Hi David, > It is reasonable that a pointer array has the distribution of its ... > conclusion is that pointer arrays cannot be allocated as distributed > arrays. Is this correct? That's correct; a pointer appearing in an ALLOCATE statement would get some compiler default distribution (probably replication). > If true, this seems highly and unnecessarily restrictive. If ..... > eliminates the possibility of REDISTRIBUTING or REALIGNING them after > allocation as well. The original interpretation request that prompted this restriction asked whether the following was a valid program - could a pointer be given one mapping and made to point at something with a different mapping. program p integer, pointer :: ptr(:) integer, target :: targ(100) !hpf$ processors proc(number_of_processors()) !hpf$ distribute targ(cyclic) onto proc !hpf$ distribute ptr(block) onto proc ptr => targ end program p HPFF decided that it would be best to avoid such problems by prohibiting the pointer from having an explicit mapping, and having it acquire the mapping of its target. This (perhaps inadvertently - I'm not sure) had the effect of preventing the user from explicitly mapping pointers when they become associated through the ALLOCATE statement. > Even without having pointer arrays, CMFortran successfully encompassed ......... > documents, I'd be wery appreciative. This issue was raised by Larry Meadows for HPF 2.0, but I'm not sure off-hand how it was dealt with at the last HPFF meeting. Does anyone recall whether this aspect of the problem came up for discussion? Thanks, Henry ---- and additional comment from Carol ---- I only recall that this came up at the vendors subgroup, where we proposed that DISTRIBUTE and ALIGN be reallowed for POINTER and ALLOCATABLE variables for precisely this reason. The idea, as I understood it, was to let POINTER arrays be mapped, but only (in the absence of DYNAMIC) allow them to point to similarly mapped variables. (I don't think we talked about the question of pointing at array sections of similarly mapped variables.) I'm not sure what the last official HPFF vote on pointers was, although I believe it implied that nondynamic pointer arrays should only point to things with the same mapping, which seems to me most compatible with their having a mapping themselves, not with their having no mapping. SEE #11 FOR CONTINUED DISCUSSION __________________________________________________ CCI #49 distribution with array border elements Group D Rosing m_rosing@pnl.gov submitted: 2/7/96 status: new (NOTE - I MUST HAVE MISSED RECORDING ACTION ON THIS ONE - IS IT OK AS ANSWERED OR DOES IT REQUIRE FURTHER ATTENTION?) question: I'm trying to figure out how to distribute two types of arrays to minimize communication, the first has border elements and the second doesn't. The first array is declared B(-2:nx+2, -2:ny+2, -2:nz+2) and the second is declared A(nx,ny,nz). Array A should be distributed by blocks in one or more dimensions and array B should be distributed such that B(i,j,k) is on the same node as A(i,j,k) for 0 a and x point to same data with different distribution: Proposal: add restriction [better words] to the pointer proposal discussed earlier The mapping of a dummy argument with a pointer attribute has to match the mapping of the actual argument if the latter is accessible inside the procedure through another path. strawpoll : 18 - 0 - 3 __________________________________________________ CCI #45 extrinsic clarifications Group E Hennecke hennecke@rz.uni-karlsruhe.de submitted: 1/23/96 status: in progress (note most of these good comments/corrections - ran out of time in March to complete list) question: Hello, some questions and comments on EXTRINSIC are added below. I assembled them when 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 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... question continued: 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 " =====continued in #46 ======================= CCI #46 extrinsic clarifications Group E Hennecke hennecke@rz.uni-karlsruhe.de submitted 1/23/96 status: in progress NOTE THIS IS A CONTINUATION OF #45 with the Annex part split into a separate item. 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" __________________________________________________ CCI #51 array sections and HPF_LOCAL Group E updated: 4/27/96 Zongaro zongaro@vnet.ibm.com submitted 2/13/96 status: in progress being discussed with #54 and #55 - see #55 for proposal question: Hello, I thought I had sent this question a few weeks ago, but I couldn't find any record of having done that - my apologies if this is a duplicate. Consider the following program. program prog interface extrinsic(hpf_local) subroutine sub(dummy) integer :: dummy(:, :) !hpf$ inherit dummy end subroutine sub end interface integer actual(4, 4) !hpf$ processors p(2, 2) !hpf$ distribute actual(block, block) onto p call sub(actual(1:2, 1:2)) end program prog extrinsic(hpf_local) subroutine sub(dummy) use hpf_local_library integer :: dummy(:, :) print *, 'proc = ', my_processor(), & & 'lbound = ', lbound(dummy), & & 'ubound = ', ubound(dummy) end subroutine sub Assuming that elements of p correspond to physical processors as follows p(1,1) 0 p(2,1) 1 p(1,2) 2 p(2,2) 3 which of the following correctly describes the output from the four instances of the HPF_LOCAL subroutine? a) proc = 0 lbound = 1 1 ubound = 2 2 proc = 1 lbound = 1 1 ubound = 0 2 proc = 2 lbound = 1 1 ubound = 2 0 proc = 3 lbound = 1 1 ubound = 0 0 b) proc = 0 lbound = 1 1 ubound = 2 2 proc = 1 lbound = 1 1 ubound = 0 0 proc = 2 lbound = 1 1 ubound = 0 0 proc = 3 lbound = 1 1 ubound = 0 0 In other words, should sub behave as if dummy is divided up like this ------------------------------------- | dummy(1:2, 1:2) | dummy(1:2, 1:0) | a) ------------------------------------- | dummy(1:0, 1:2) | dummy(1:0, 1:0) | ------------------------------------- or this? ------------------------------------- | dummy(1:2, 1:2) | dummy(1:0, 1:0) | b) ------------------------------------- | dummy(1:0, 1:0) | dummy(1:0, 1:0) | ------------------------------------- Thanks, Henry Rob replies ... Henry, Good question about lbound and ubound for dummies of extrinsic local routines! I favor iterpretation (a) ------------------------------------- | dummy(1:2, 1:2) | dummy(1:2, 1:0) | a) ------------------------------------- | dummy(1:0, 1:2) | dummy(1:0, 1:0) | ------------------------------------- All HPF distributions onto multidimensional processors arrangements are cartesian products of one-dimensional distributions; this interpretation is consistent with that rule. Rob ----- comment from David Watson dave@nasoftwr.demon.co.uk --- Can I add support for interpretation a) i.e. ------------------------------------- | dummy(1:2, 1:2) | dummy(1:2, 1:0) | ------------------------------------- | dummy(1:0, 1:2) | dummy(1:0, 1:0) | ------------------------------------- If we consider a function or subroutine delivering a result sized according to an incoming argument this interpretation is necessary for correct behaviour. The following (exceedingly artificial) code illustrates the necessity program prog interface extrinsic(hpf_local) function funres(dummy) integer :: dummy(:, :) integer :: funres(size(dummy,1)) !hpf$ inherit dummy !hpf$ align with dummy(:,*) :: funres end subroutine funres end interface integer actual(4, 4) integer junk(4) !hpf$ processors p(2, 2) !hpf$ distribute actual(block, block) onto p !hpf$ align junk(:) with actual(:,*) junk(1:2) = funres(actual(1:2,1:2)) end program prog extrinsic(hpf_local) function funres(dummy) integer :: dummy(:, :) integer :: funres(size(dummy,1)) !hpf$ inherit dummy !hpf$ align with dummy(:,*) :: funres funres = 0 dummy = 0 end subroutine funres under interpretation b) processor 2 (assuming the numbering in the original example) would return a size zero array into a size 2 array. Cheers, Dave #51, 54 and 55 being discussed together - see #55 for proposal. __________________________________________________ CCI #54 local inquiry about globals Group E updated: 4/27/96 Offner offner@hpc.pko.dec.com submitted:3/7/96 status: in progress being discussed with #51 and #55 - see #55 for proposal question: 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 -------- beginning of reply from Chuck 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 ... >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 >... >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 itsinputs." >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 >.... >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 about pt 1 above - Henry comments: 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. and about point 2 above Henry comments: 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. #51, 54, and 55 being discussed together - see #55 for proposal __________________________________________________ CCI #55 more global/local bound questions Group E updated: 4/27/96 Meadows lfm@pgroup.com submitted: 3/08/96 status: in progress question: 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 ------ DISCUSSION FROM MARCH MEETING - #51,54, and this together ... proposal: first reading remove global_ub/lb from HPF2 Motivation: global_shape etc. do the same thing. Henry believes he asked for these functions and no longer needs them. As a formal 1st reading, we will have time to reconsider. Vote: 17 - 0 - 1 __________________________________________________ CCI #57 HPF_LOCAL and assumed size arrays Group E Whaley rwhaley@c.utk.edu submitted: 3/22/96 status: new question: 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 --------end of question - ---- beginning of discussion --------- Mary comments: Good point ... We already have wording here and there that distinguishes the HPF_LOCAL routines that may be called from global from the others ... it seems completely reasonable to me that the assumed shape requirement would apply only to those routines that cross that boundary. Formally - your question will go on the list for the next meeting (May 1-3). -mary- ----------- Carl comments: 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 --------- Clint replies: 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? Thanks, Clint ------------------------ Back to Carl: 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 ------------------------- and back to Clint: 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 ---------------------- And - now a comment from Carol: 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 ---------------------------- And a couple more comments from Carl: 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 ------------------------------------- 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-core-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------