From owner-hpff-interpret Thu Oct 3 13:48:05 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA04969 for hpff-interpret-out; Thu, 3 Oct 1996 13:48:05 -0500 (CDT) Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id NAA04917; Thu, 3 Oct 1996 13:47:25 -0500 (CDT) Received: from beta.lanl.gov (beta.lanl.gov [128.165.1.160]) by mailhost.lanl.gov (8.7.6/8.7.3) with SMTP id MAA24859; Thu, 3 Oct 1996 12:47:23 -0600 (MDT) Received: by beta.lanl.gov (AIX 4.1/UCB 5.64/4.03) id AA27094; Thu, 3 Oct 1996 12:47:23 -0600 Date: Thu, 3 Oct 1996 12:47:23 -0600 From: wrb@beta.lanl.gov (Bob Boland) Message-Id: <9610031847.AA27094@beta.lanl.gov> To: comp-fortran-90@mailbase.ac.uk, hpff-core@cs.rice.edu, hpff-distribute@cs.rice.edu, hpff-doc@cs.rice.edu, hpff-interpret@cs.rice.edu, hpff-task@cs.rice.edu Subject: hpff-interpret: HPF User Group Meeting Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ First Annual HPF User Group Meeting !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ Sante Fe, New Mexico !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ February 24-26, 1997, Eldorado Hotel !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ !HPF$ Sponsored by ============ Center for Research on Parallel Computation Los Alamos National Laboratory ======================================================================= The First Annual HPF User Group Meeting will be held February 24 to 26, 1997, at the Eldorado Hotel in Sante Fe, New Mexico. At this time, it is anticipated that the meeting will end around noon on Wednesday. The meeting will provide an opportunity for users of HPF to meet each other, share ideas and experience, and get up-to-date information about implementations and future directions. The day before the conference (February 23) will be devoted to tutorials: o Introduction to HPF (morning) Covering the basics of programming in HPF. o HPF 2.0 (afternoon) Presentation of the newly-finalized HPF version 2.0. The conference itself will include: o Invited Talks by HPF users o Invited Talks by HPF developers o Panel Discussions Ken Kennedy will moderate a panel discussion to promote user feedback on HPF. The particular focuses of this panel will be to advise compiler developers on where to focus their efforts: What features do programmers use? What features need better implementations? Attendee participation is highly encouraged. Other panels may be added based on attendee interest. Proposals for panel sessions may be submitted through the "contributed talks" mechanism. o Contributed Talks from the HPF user community o Social Activities An opening reception will be held at the hotel Sunday evening. A banquet on Tuesday evening will be held at the hotel. Conference attendees are encouraged to submit abstracts for presentations at the meeting. Call For Presentations: ----------------------- We invite everyone with HPF ideas or experiences to submit abstracts of papers and posters for possible presentation at the meeting. List of topics includes (but is not limited to): o Real-world HPF Applications: CFD Image Processing Structural Analysis Chemistry Aerodynamics o HPF Software: Tools Libraries Vendors Implementations Programming Environments o HPF Development: Extensions and Improvements Optimization Techniques Runtime Support Critiques and Evaluations Submitting an abstract: ----------------------- Abstracts of 300 words or less must be submitted before January 2, 1997 and must be in a single file readable by Netscape 2.0 or later. Abstracts will be reviewed and authors notified of their acceptance by January 16, 1997. Accepted abstracts will be posted on the Web and the meeting program will be prepared directly from the submitted abstract. Submit abstracts to hpf97@lanl.gov. Any special equipment required for the talk should also be indicated in the abstract. Important Dates: ---------------- January 2: Abstract submission deadline January 16: Speaker notification January 24: Registration deadline for meeting and tutorials (to avoid late fee) Additional information can be retrieved on the World Wide Web at: http://www.lanl.gov/HPF High Performance Fortran User Group Program Committee: ------------------------------------------------------ Bob Boland, LANL (chair) (wrb@lanl.gov) Barbara Chapman, University of Vienna (barbara@vcpc.univie.ac.at) Dave Loveman, Digital (loveman@msbcs.enet.dec.com) Ken Kennedy, Rice University (ken@rice.edu) Charles Koelbel, Rice University (chk@cs.rice.edu) David L. Presberg, Cornell Theory Center (presberg@tc.cornell.edu) Mary Zosel, LLNL (zosel@llnl.gov) Registration: ------------- In order to establish your registration please complete the accompanying form and return to hutton@lanl.gov no later than January 24, 1997. The registration fee for the conference is $200.00 if received by January 24. Late registration fee (received after January 24) will be $250.00. The fee for the tutorials is $25.00 per tutorial if received no later than January 24, 1997 and $40.00 otherwise. Fees can be paid by cash, check, Visa or Mastercard only. Credit cards will not be charged until just prior to the conference. Please mail checks (made payable to HPF User Group) or credit card information to: LeeRoy Herrera Los Alamos National Laboratory Conference & Visit Management, MS P366 Attn: Conference Accountant/ U9D5 Los Alamos, New Mexico 87545 Accommodations: --------------- A block of rooms has been reserved at the Eldorado Hotel. To secure accommodations at the prevailing per diem rate of $86.00 single or $108 double inclusive, contact the hotel directly and refer to the HPF meeting. Reservations must be made by January 24, 1997, to ensure the conference rate. Reservations made after that date will be on a space available basis. Eldorado Hotel 309 W. San Francisco St Santa Fe, New Mexico 86501 800-955-4455 (Reservations) / 505-988-4455 Parking: -------- Valet parking is available at the Eldorado at the rate of $7 per 24 hour period. Hospitality: ------------ A welcoming hosted reception (and on-site registration) will be held at the hotel Sunday evening from 6:00 to 8:00 p.m. Light refreshments will be served during morning and afternoon breaks. A banquet is planned for Tuesday, February 25, at 7:00 p.m. at the Eldorado Hotel. Guest banquet tickets may be purchased for $40.00. Transportation: --------------- Rental cars are available at the Albuquerque International Airport. Santa Fe is approximately 1 1/2 hours drive from Albuquerque. Contact LeeRoy Herrera at the number listed above if a map is needed (or see the WWW page listed below). Shuttlejack bus transportation is also available from the airport directly to the hotel at a cost of approximately $20 each way. Contact Shuttlejack directly at 800-452-2665 (outside of New Mexico) or 505-243-3244 to arrange transportation. Special Accommodations: ----------------------- Every effort will be made to accommodate special needs of disabled participants or those with dietary restrictions. If assistance is required, please contact LeeRoy Herrera at 505-665-5593. Weather and Dress: ------------------ Casual dress is appropriate for this conference. In February days are usually sunny and cool and evenings are cold with temperatures in the 30 to 40 degree range. Snow is a possibility. A coat is recommended. REGISTRATION FORM HIGH PERFORMANCE FORTRAN (HPF) USERS GROUP Eldorado Hotel February 24 - 26, 1995 Name: _______________________________________ Address: _______________________________________ _______________________________________ _______________________________________ _______________________________________ Telephone: _____________________________ FAX: _____________________________ E-mail address: _____________________________ Dietary restrictions: Vegetarian _____ Kosher ______ Registration Fee: ($200.00 on or before January 24, 1997 and $250.00 after January 24, 1997) ____________ Introduction to HPF tutorial: ($25.00 on or before January 24, 1997 and $40.00 after January 24, 1997) ____________ HPF 2.0 tutorial: ($25.00 on or before January 24, 1997 and $40.00 after January 24, 1997) ____________ Guest Banquet Tickets: ______ at $40.00 per person ____________ Total ____________ Non-LANL Participants: Payment Made By: Cash ____ Check _____ Credit Card _____ Credit Card Information: Mastercard _______ Visa ______ Account Number _____________________________ Expiration Date _________ LANL Participants: Please provide your cost and program code and cost account ________/________/________ I plan to attend the following: Reception (Feb. 23) ________ Banquet (Feb. 25) ________ --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Oct 14 00:05:54 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id AAA15747 for hpff-interpret-out; Mon, 14 Oct 1996 00:05:54 -0500 (CDT) Received: from [128.42.5.179] (pasyn-51.rice.edu [128.42.5.179]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id AAA15738; Mon, 14 Oct 1996 00:05:24 -0500 (CDT) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Oct 1996 22:54:34 -0500 To: hpff-interpret From: Chuck Koelbel Subject: hpff-interpret: HPF: dimensioning a processor arrangement by number_of_processors() Cc: gale@hpc.pko.dec.com Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- I'm forwarding this question (originally sent to the comp-fortran-90 list): >Date: Fri, 11 Oct 1996 12:39:54 -0400 >From: Israel Gale >To: comp-fortran-90@mailbase.ac.uk >Cc: gale@hpc.pko.dec.com >Subject: HPF: dimensioning a processor arrangement by number_of_processors() >Reply-To: gale@hpc.pko.dec.com >X-Unsub: To leave, send text 'leave comp-fortran-90' > to mailbase@mailbase.ac.uk >Sender: comp-fortran-90-request@mailbase.ac.uk >Precedence: list > >I have recently come across an annoying problem in HPF: If you dimension >a processor arrangement by number_of_processors(), the processor >arrangement is an automatic data object according to the F90 standard, and >is illegal in a main program. > >Examples like: > >!hpf$ processors P(number_of_processors()) > >are constantly bandied about in official HPF publications (like the HPF >Handbook), which tells me that this illegal example was designed to be one >of the main intended uses of number_of_processors(). > >One work-around that has been suggested is to write a main program that is >nothing but a wrapper for a procedure which contains your "real" main >program. Automatic data objects are permitted in procedures, so the >problem goes away. > >Does anyone see any disadvantages to this approach? > >-Israel Gale > gale@hpc.pko.dec.com > Statement 1: I'm not sure what constitutes an "official" publication, since HPFF is not part of any recognized national or international standards body. And the Handbook, while written by members of HPFF, was not approved by the HPFF committee. But it is true that this sort of example has shown up in a lot of places. Statement 2: Another workaround is to use a parameter statment. PARAMETER (NP=NUMBER_OF_PROCESSORS()) !HPF$ PROCESSORS PROCS(NP) I believe this is allowed everywhere. Statement 3: I don't see any disadvantage to your approach. Of course, I'm sure others will have some additional comments. Chuck ********************************************************************** Charles Koelbel CITI/CRPC, MS 41 Center for Research on Parallel Computation Rice University Rice University 6100 Main Street chk@cs.rice.edu Houston, TX 77005 ********************************************************************** --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Oct 14 05:29:33 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id FAA19809 for hpff-interpret-out; Mon, 14 Oct 1996 05:29:33 -0500 (CDT) Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id FAA19803; Mon, 14 Oct 1996 05:29:16 -0500 (CDT) Message-Id: <199610141029.FAA19803@cs.rice.edu> Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Mon, 14 Oct 1996 11:14:22 +0200 Received: by ry73.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA045754459; Mon, 14 Oct 1996 11:14:19 +0200 Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by To: chk@cs.rice.edu (Chuck Koelbel) Date: Mon, 14 Oct 1996 11:14:18 +0200 (CES) Cc: gale@hpc.pko.dec.com, hpff-interpret@cs.rice.edu, comp-fortran-90@mailbase.ac.uk In-Reply-To: from "Chuck Koelbel" at Oct 13, 96 10:54:34 pm From: hennecke@rz.uni-karlsruhe.de (Michael Hennecke) Reply-To: hennecke@rz.uni-karlsruhe.de (Michael Hennecke) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- According to Chuck Koelbel: > >I have recently come across an annoying problem in HPF: If you dimension > >a processor arrangement by number_of_processors(), the processor > >arrangement is an automatic data object according to the F90 standard, and > >is illegal in a main program. > > Statement 2: > Another workaround is to use a parameter statment. > PARAMETER (NP=NUMBER_OF_PROCESSORS()) > !HPF$ PROCESSORS PROCS(NP) > I believe this is allowed everywhere. No, this is even worse and also flagged by all the compilers I have: An must contain an (as the name implies :-), and NUMBER_OF_PROCESSORS() isn't one. An may contain a , which is much less restrictive. Only if the bounds are NONCONSTANT specification expressions does the above problem arise. For example PROGRAM constant REAL :: a(100) REAL :: b(SIZE(a)) END PROGRAM constant is completely legal Fortran. I think it must be stated in the HPF spec that NUMBER_OF_PROCESSORS() belongs to the list of intrinsics which may be used in a <>. This list is in F95, 7.1.6.2., and the HPF spec may wish to extend this list. Best regards, Michael ====================================================================== Michael Hennecke http://www.uni-karlsruhe.de/~Michael.Hennecke/ ---------------------------------------------------------------------- University of Karlsruhe RFC822: hennecke@rz.uni-karlsruhe.de Computing Center (G20.21 R210) No longer on BITNET :-( Zirkel 2 * P.O. Box 69 80 Phone: +49 721 608-4862 D-76128 Karlsruhe Fax: +49 721 32550 ====================================================================== --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Oct 14 12:00:17 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA27635 for hpff-interpret-out; Mon, 14 Oct 1996 12:00:17 -0500 (CDT) Received: from pacific.pgroup.com (pacific.pgroup.com [192.124.124.8]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id MAA27629 for ; Mon, 14 Oct 1996 12:00:13 -0500 (CDT) Received: (from lfm@localhost) by pacific.pgroup.com (8.7.6/8.6.11) id JAA07914; Mon, 14 Oct 1996 09:59:34 -0700 (PDT) Message-Id: <199610141659.JAA07914@pacific.pgroup.com> Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by In-Reply-To: <199610141029.FAA19803@cs.rice.edu> from Michael Hennecke at "Oct 14, 96 11:14:18 am" To: hennecke@rz.uni-karlsruhe.de Date: Mon, 14 Oct 1996 09:59:33 -0700 (PDT) From: Larry Meadows Cc: hpff-interpret@cs.rice.edu, gale@hpc.pko.dec.com, zongaro@vnet.ibm.com X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > According to Chuck Koelbel: > > >I have recently come across an annoying problem in HPF: If you dimension > > >a processor arrangement by number_of_processors(), the processor > > >arrangement is an automatic data object according to the F90 standard, and > > >is illegal in a main program. > > > > Statement 2: > > Another workaround is to use a parameter statment. > > PARAMETER (NP=NUMBER_OF_PROCESSORS()) > > !HPF$ PROCESSORS PROCS(NP) > > I believe this is allowed everywhere. > > No, this is even worse and also flagged by all the compilers I have: > An must contain an (as the name > implies :-), and NUMBER_OF_PROCESSORS() isn't one. I'm almost certain that it was the intent of the Forum for number_of_processors() to be a *constant* expression. This program compiles fine with pghpf: !hpf$ processors p(number_of_processors()) real a(100) common /junk/ a !hpf$ distribute (block) onto p:: a a = 100 print *,a end It also compiles fine with IBM's xlhpf. Digital's compiler, however, says: f90: Error: bug.f90, line 1: Explicit-shape-specs in a PROCESSORS directive must be constant expressions in a main program. [P] !hpf$ processors p(number_of_processors()) lfm --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Oct 14 13:06:08 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA29786 for hpff-interpret-out; Mon, 14 Oct 1996 13:06:08 -0500 (CDT) Received: from millepore-f.icase.edu (millepore-f.icase.edu [146.165.142.169]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id NAA29778 for ; Mon, 14 Oct 1996 13:06:05 -0500 (CDT) Received: from localhost by millepore-f.icase.edu with SMTP (8.6.11/lanleaf8.6.4) id OAA06130; Mon, 14 Oct 1996 14:05:07 -0400 Date: Mon, 14 Oct 1996 14:05:06 -0400 (EDT) From: Piyush Mehrotra To: Larry Meadows cc: hennecke@rz.uni-karlsruhe.de, hpff-interpret@cs.rice.edu, gale@hpc.pko.dec.com, zongaro@vnet.ibm.com Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by In-Reply-To: <199610141659.JAA07914@pacific.pgroup.com> Message-ID: Phone: (757)-864-2188 Fax: (757)-864-6134 WWW: http://www.icase.edu/~pm Address: ICASE MS 403 NASA Langley Research Center Hampton VA 23681 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > --------------------------------------------------------------------------- > hpff-interpret@cs.rice.edu is a mailing list for corrections, > clarifications, and interpretations related to High Performance Fortran. > Instructions for adding or deleting yourself from this list appear at the > bottom of this message. > --------------------------------------------------------------------------- > > > According to Chuck Koelbel: > > > >I have recently come across an annoying problem in HPF: If you dimension > > > >a processor arrangement by number_of_processors(), the processor > > > >arrangement is an automatic data object according to the F90 standard, and > > > >is illegal in a main program. > > > > > > Statement 2: > > > Another workaround is to use a parameter statment. > > > PARAMETER (NP=NUMBER_OF_PROCESSORS()) > > > !HPF$ PROCESSORS PROCS(NP) > > > I believe this is allowed everywhere. > > > > No, this is even worse and also flagged by all the compilers I have: > > An must contain an (as the name > > implies :-), and NUMBER_OF_PROCESSORS() isn't one. > > I'm almost certain that it was the intent of the Forum for > number_of_processors() to be a *constant* expression. Here is the relevant text from Section 5 (page 91) Version 1.1 of the HPF document: The values returned by the system inquiry intrinsic functions remain constant for the duration of one program execution. Thus, {\tt NUMBER_OF_PROCESSORS} and {\tt PROCESSORS_SHAPE} have values that are restricted expressions and may be used wherever any other Fortran restricted expression may be used. In particular, {\tt NUMBER_OF_PROCESSORS} may be used in a specification expression. The values of system inquiry functions may not occur in initialization expressions, because they may not be assumed to be constants. In particular, HPF programs may be compiled to run on machines whose configurations are not known at compile time. Thus, it was clearly the intent of the forum to *not* make it a constant expression (see reasoning above). - Piyush > > This program compiles fine with pghpf: > > !hpf$ processors p(number_of_processors()) > real a(100) > common /junk/ a > !hpf$ distribute (block) onto p:: a > a = 100 > print *,a > end > > It also compiles fine with IBM's xlhpf. > > Digital's compiler, however, says: > > f90: Error: bug.f90, line 1: Explicit-shape-specs in a PROCESSORS directive must be constant expressions in a main program. [P] > !hpf$ processors p(number_of_processors()) > > lfm > --------------------------------------------------------------------------- > To (un)subscribe to this list, send mail to > hpff-interpret-request@cs.rice.edu. > Leave the subject line blank, and in the body put the line > (un)subscribe > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Oct 14 13:14:28 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA00363 for hpff-interpret-out; Mon, 14 Oct 1996 13:14:28 -0500 (CDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id NAA00351 for ; Mon, 14 Oct 1996 13:14:25 -0500 (CDT) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA09015; Mon, 14 Oct 1996 14:00:41 -0400 Received: by mpsg.hpc.pko.dec.com; id AA06245; Mon, 14 Oct 1996 14:03:29 -0400 Received: by wind.hpc.pko.dec.com; (5.65v3.2/1.1.8.2/06Jun95-1053AM) id AA24625; Mon, 14 Oct 1996 14:00:24 -0400 Date: Mon, 14 Oct 1996 14:00:24 -0400 Message-Id: <9610141800.AA24625@wind.hpc.pko.dec.com> From: Israel Gale To: lfm@pgroup.com Cc: hennecke@rz.uni-karlsruhe.de, hpff-interpret@cs.rice.edu, zongaro@vnet.ibm.com In-Reply-To: <199610141659.JAA07914@pacific.pgroup.com> (message from Larry Meadows on Mon, 14 Oct 1996 09:59:33 -0700 (PDT)) Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by Reply-To: gale@hpc.pko.dec.com Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Larry Meadows wrote: > I'm almost certain that it was the intent of the Forum for > number_of_processors() to be a *constant* expression. > > This program compiles fine with pghpf: > > !hpf$ processors p(number_of_processors()) > real a(100) > common /junk/ a > !hpf$ distribute (block) onto p:: a > a = 100 > print *,a > end > > It also compiles fine with IBM's xlhpf. > > Digital's compiler, however, says: > > f90: Error: bug.f90, line 1: Explicit-shape-specs in a PROCESSORS directive must be constant expressions in a main program. [P] > !hpf$ processors p(number_of_processors()) Let me re-phrase Larry's comment: I think Larry is interpreting the HPF Specification to relax the F90 standard and allow number_of_processors() wherever a constant expression is allowed, even if it is not actually known at compile time. In other words, automatic data objects are not allowed in main programs, unless they are dimensioned with number_of_processors(), in which case they _are_ allowed. This is apparently IBM's interpretation, as well. Digital's compiler interprets the F90 standard strictly, and gives the error message that Larry reported, whenever the value of number_of_processors() is not known at compile time. Digital has a compile-time option that produces an executable that is optimized for a specified number of processors. When this option is used, the value number_of_processors() _is_ known at compile time, and we treat it as a constant, allowing number_of_processors() to dimension data objects even in a main program. If I got this right, it means that our differing implementations have uncovered an ambiguity in the HPF Specification. -Israel Gale gale@hpc.pko.dec.com --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Oct 14 13:41:58 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA01659 for hpff-interpret-out; Mon, 14 Oct 1996 13:41:58 -0500 (CDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id NAA01635 for ; Mon, 14 Oct 1996 13:41:53 -0500 (CDT) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA06331; Mon, 14 Oct 1996 14:30:31 -0400 Received: by mpsg.hpc.pko.dec.com; id AA06418; Mon, 14 Oct 1996 14:33:18 -0400 Received: by wind.hpc.pko.dec.com; (5.65v3.2/1.1.8.2/06Jun95-1053AM) id AA24541; Mon, 14 Oct 1996 14:30:14 -0400 Date: Mon, 14 Oct 1996 14:30:14 -0400 Message-Id: <9610141830.AA24541@wind.hpc.pko.dec.com> From: Israel Gale To: pm@icase.edu Cc: lfm@pgroup.com, hennecke@rz.uni-karlsruhe.de, hpff-interpret@cs.rice.edu, zongaro@vnet.ibm.com In-Reply-To: (message from Piyush Mehrotra on Mon, 14 Oct 1996 14:05:06 -0400 (EDT)) Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by Reply-To: gale@hpc.pko.dec.com Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Piyush Mehrotra wrote: > Here is the relevant text from Section 5 (page 91) Version 1.1 of > the HPF document: > > The values returned by the system inquiry intrinsic functions remain > constant for the duration of one program execution. Thus, {\tt > NUMBER_OF_PROCESSORS} and {\tt PROCESSORS_SHAPE} have values that are > restricted expressions and may be used wherever any other Fortran > restricted expression may be used. In particular, {\tt > NUMBER_OF_PROCESSORS} may be used in a specification expression. I'm afraid the language of the spec does little to clarify this issue. The spec does not distinguish between main programs and procedures. It is not clearly stated here that this was meant to relax the F90 rule on automatic data objects. -Israel Gale gale@hpc.pko.dec.com --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Oct 15 08:19:18 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id IAA28728 for hpff-interpret-out; Tue, 15 Oct 1996 08:19:18 -0500 (CDT) Received: from relay-1.mail.demon.net (relay-1.mail.demon.net [158.152.1.140]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id IAA28722 for ; Tue, 15 Oct 1996 08:19:15 -0500 (CDT) Received: from post.demon.co.uk ([(null)]) by relay-1.mail.demon.net id ad02563; 15 Oct 96 14:12 BST Received: from nasoftwr.demon.co.uk ([158.152.18.126]) by relay-3.mail.demon.net id aa15951; 15 Oct 96 14:06 BST Received: from ferrari.nasoftware by nasoftwr.demon.co.uk id OAA05005; Tue, 15 Oct 1996 14:01:27 +0100 From: Dave Watson Received: by ferrari.nasoftware id AA15149; Tue, 15 Oct 96 14:01:26 BST Local-From: dave@ferrari (Dave Watson) Message-Id: <9610151301.AA15149@ferrari.nasoftware> Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by To: gale@hpc.pko.dec.com Date: Tue, 15 Oct 1996 14:01:26 +0100 (BST) Cc: hpff-interpret@cs.rice.edu In-Reply-To: <9610141830.AA24541@wind.hpc.pko.dec.com> from "Israel Gale" at Oct 14, 96 02:30:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > > Piyush Mehrotra wrote: > > > Here is the relevant text from Section 5 (page 91) Version 1.1 of > > the HPF document: > > > > The values returned by the system inquiry intrinsic functions remain > > constant for the duration of one program execution. Thus, {\tt > > NUMBER_OF_PROCESSORS} and {\tt PROCESSORS_SHAPE} have values that are > > restricted expressions and may be used wherever any other Fortran > > restricted expression may be used. In particular, {\tt > > NUMBER_OF_PROCESSORS} may be used in a specification expression. > > I'm afraid the language of the spec does little to clarify this issue. > The spec does not distinguish between main programs and procedures. It is > not clearly stated here that this was meant to relax the F90 rule on > automatic data objects. > > -Israel Gale Read in cojunction with section 5.1.2.4.1 "Explicit-shape array" of the F90 standard I believe that text from Section 5 is unambiguous and that NUMBER_OF_PROCESSORS is not allowed to dimension an array in the main program. The relevant constraint is: " An explicit-shape array whose bounds depend on the values of non-constant expressions must be a dummy argment, a function result or an automatic array of a procedure." --------- If NUMBER_OF_PROCESSORS were to be considered a constant expression this would require that both SAVE'd and COMMON arrays could also be dimensioned with expressions dependent on NUMBER_OF_PROCESSORS. I do not think that this is intended. cheers Dave Watson --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Oct 15 09:35:26 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA00543 for hpff-interpret-out; Tue, 15 Oct 1996 09:35:26 -0500 (CDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id JAA00538 for ; Tue, 15 Oct 1996 09:35:20 -0500 (CDT) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3059; Tue, 15 Oct 96 10:35:14 EDT Received: by TOROLAB (XAGENTA 4.0) id 0461; Tue, 15 Oct 1996 10:37:38 -0400 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA22356; Tue, 15 Oct 1996 10:32:58 -0400 From: (Henry Zongaro) Message-Id: <9610151432.AA22356@twinpeaks.torolab.ibm.com> Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by To: gale@hpc.pko.dec.com Date: Tue, 15 Oct 1996 10:32:56 -0400 (EDT) Cc: pm@icase.edu, lfm@pgroup.com, hennecke@rz.uni-karlsruhe.de, hpff-interpret@cs.rice.edu In-Reply-To: <9610141830.AA24541@wind.hpc.pko.dec.com> from "Israel Gale" at Oct 14, 96 02:30:14 pm X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Hello, > Piyush Mehrotra wrote: > > > Here is the relevant text from Section 5 (page 91) Version 1.1 of > > the HPF document: > > > > The values returned by the system inquiry intrinsic functions remain > > constant for the duration of one program execution. Thus, {\tt > > NUMBER_OF_PROCESSORS} and {\tt PROCESSORS_SHAPE} have values that are > > restricted expressions and may be used wherever any other Fortran > > restricted expression may be used. In particular, {\tt > > NUMBER_OF_PROCESSORS} may be used in a specification expression. > > I'm afraid the language of the spec does little to clarify this issue. > The spec does not distinguish between main programs and procedures. It is > not clearly stated here that this was meant to relax the F90 rule on > automatic data objects. Sorry I'm late jumping into this thread - yesterday was Thanksgiving Day here in Canada. Interpretation Item 13 against HPF 1.1 deals with this issue. The final reponse was to delete the paragraph that Piyush cites above and the paragraph that follows it, and to replace them with the following text: "The Fortran 90 definition of restricted expression is extended to permit references to the HPF system inquiry intrinsic functions. In particular, at the end of the numbered list in 7.1.6.2 [of Fortran 90], add: (11) A reference to one of the system inquiry functions NUMBER_OF_PROCESSORS and PROCESSORS_SHAPE, where any argument is a restricted expression. A variable which appears in a restricted expression in an HPF directive in the scoping unit of a module or main program must be an implied-DO variable, or must be an argument in a reference to an array inquiry function, bit inquiry function, character inquiry function, kind inquiry function or numeric inquiry function." NUMBER_OF_PROCESSORS or PROCESSORS_SHAPE were not added to the list of functions permitted in constant expressions or initialization expressions, so they are not permitted as part of a specification expression for array bounds or character lengths in main program or module scoping units. So there's no problem with ordinary data objects here. We don't want template or processor arrangement bounds to be similarly restricted. Since they are not automatic objects (templates and processors are not objects, so they can't be automatic objects), there's no problem with declaring them to have bounds that are not constant specification expressions in the main program or a module scoping unit. The added restriction that appears beneath item (11) ensures that the only non-constant parts of such an expression come in through references to NUMBER_OF_PROCESSORS or PROCESSORS_SHAPE. The following problematic example is prohibited by the above wording: module mod1 integer :: i end module mod1 module mod2 use mod1 !hpf$ processors proc(i, number_of_processors()/i) end module mod2 program p use mod1 i = 1 call sub i = 0 call sub end program p subroutine sub use mod2 ! Do the bounds of proc change? end subroutine sub Hope this helps. Thanks, Henry --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Oct 15 10:13:48 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA01947 for hpff-interpret-out; Tue, 15 Oct 1996 10:13:48 -0500 (CDT) Received: from theory.tc.cornell.edu (THEORY.TC.CORNELL.EDU [132.236.98.174]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id KAA01937 for ; Tue, 15 Oct 1996 10:13:44 -0500 (CDT) Received: (from presberg@localhost) by theory.tc.cornell.edu (8.6.9/8.6.6) id LAA52690; Tue, 15 Oct 1996 11:13:42 -0400 Date: Tue, 15 Oct 1996 11:13:42 -0400 Message-Id: <199610151513.LAA52690@theory.tc.cornell.edu> From: David Presberg To: hpff-interpret@cs.rice.edu Cc: gale@hpc.pko.dec.com, Dave Watson , presberg@tc.cornell.edu Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by In-Reply-To: <9610151301.AA15149@ferrari.nasoftware> References: <9610141830.AA24541@wind.hpc.pko.dec.com> <9610151301.AA15149@ferrari.nasoftware> Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Folks -- I am not clear as to why the discussion has shifted from the original concern: > ...If you dimension >a processor arrangement by number_of_processors(), the processor ^^^^^^^^^^^^^^^^^^^^^ >arrangement is an automatic data object according to the F90 standard, and >is illegal in a main program. [from Message-Id: , Koelbel (for Israel Gale ), Sun, 13 Oct 1996 22:54:34 -0500; my emphasis] to a concern about dimensioning an ARRAY using number_of_processors(). The latter issue is clearly covered by the definitions in the F90 (soon to be F95) standard, and would hang on the status of number_of_processors() as defined in HPF ("constant expression" vs. "restricted expression", both of which are semantic notions, not strictly c.f.g. general class names). Note that there are non-HPF inquiry functions in F90 that fall in the category "constant expression" when their arguments are appropriate, and in "specification expression" similarly. If HPFF proposed to change the text of HPF 1.1, Section 5.2, page 91, lines 39 .. 43, (quoted by Chuck Koelbel) to assert that number_of_processors() was in the "constant expression" category per F90, Section 7.1.6.1, much of the discussion about ARRAY declarations would shift accordingly. And the note about that function controlling the declared extents of COMMON arrays (why the extra issue about SAVE?) would have to be accomodated by HPF vendors' run time systems: they either would have the infrastructure in place to accomodate it or not, and would vote accordingly in HPFF. (I give a talk about HPF in which I have the aside: "HPF COMMON is not your grandfather's ...") But a "processor arrangement" is entirely an HPF idea, and there isn't any declared, instantiated, program object that corresponds. Again, I fully understand how various compilation strategies (and supporting run time systems) could prefer that all the details of a processor arrangement be known at compile time, and some others might be capable of handling the more dynamic (from run to run) unknown when processor arrangement depends on the encountered number of processors at the particular run. But I don't see how that distinction is any different than using number_of_processors() in, say, the int-expr of a dist-format (see HPF 1.1, section 3.2, syntax rule H309, page 26, lines 41 .. 44 (approx)). That is, one can pick apart a number_of_processors() quantity of "nodes" to set up one's favorite BLOCK(N) parameter. Do the compilers (more than one was implicated) that refuse: !HPF$ PROCESSORS R(8, NUMBER_OF_PROCESSORS()/8) also refuse: !HPF$ DISTRIBUTE A(BLOCK(8), BLOCK(NUMBER_OF_PROCESSORS()/8) ) ?? -- Pres - ------------------------------------------------------------------------ - David L. Presberg, Parallel Computing Specialist, CTC/ST/Tools - Cornell Theory Center, 740 Frank H.T. Rhodes Hall, Cornell University, - Ithaca, NY 14853-3801, USA 607-254-8861 presberg@tc.cornell.edu - Nickname: Pres - ------------------------------------------------------------------------ --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Oct 15 10:57:07 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA03777 for hpff-interpret-out; Tue, 15 Oct 1996 10:57:07 -0500 (CDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id KAA03771 for ; Tue, 15 Oct 1996 10:57:03 -0500 (CDT) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA11284; Tue, 15 Oct 1996 11:45:21 -0400 Received: by mpsg.hpc.pko.dec.com; id AA13364; Tue, 15 Oct 1996 11:48:14 -0400 Received: by wind.hpc.pko.dec.com; (5.65v3.2/1.1.8.2/06Jun95-1053AM) id AA18177; Tue, 15 Oct 1996 11:45:11 -0400 Date: Tue, 15 Oct 1996 11:45:11 -0400 Message-Id: <9610151545.AA18177@wind.hpc.pko.dec.com> From: Israel Gale To: zongaro@vnet.ibm.com Cc: pm@icase.edu, lfm@pgroup.com, hennecke@rz.uni-karlsruhe.de, hpff-interpret@cs.rice.edu In-Reply-To: <9610151432.AA22356@twinpeaks.torolab.ibm.com> (message from Henry Zongaro on Tue, 15 Oct 1996 10:32:56 -0400 (EDT)) Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by Reply-To: gale@hpc.pko.dec.com Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Henry Zongaro writes: > Interpretation Item 13 against HPF 1.1 deals with this issue. . . . > > We don't want template or processor arrangement bounds to be similarly > restricted. Since they are not automatic objects (templates and processors > are not objects, so they can't be automatic objects), there's no problem with > declaring them to have bounds that are not constant specification expressions > in the main program or a module scoping unit. The added restriction that > appears beneath item (11) ensures that the only non-constant parts of such an > expression come in through references to NUMBER_OF_PROCESSORS or > PROCESSORS_SHAPE. Thanks to Henry for pointing out this interpretation that we somehow missed. To date, this has not been a problem for our users, probably because our users generally use our feature that allows them to provide number of processors information on the compile-time command line (we then treat number_of_processors() as a constant). We will, of course, incorporate this interpretation into our next release. -Israel Gale gale@hpc.pko.dec.com --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Oct 15 21:15:40 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id VAA22206 for hpff-interpret-out; Tue, 15 Oct 1996 21:15:40 -0500 (CDT) Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id VAA22201 for ; Tue, 15 Oct 1996 21:15:34 -0500 (CDT) Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA14095 for hpff-interpret@cs.rice.edu; Tue, 15 Oct 96 19:15:24 MST Received: from txbc.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA04577 for hpff-interpret@cs.rice.edu; Tue, 15 Oct 96 19:15:23 MST Received: from wave.sps.mot.com by txbc.sps.mot.com with SMTP (1.38.193.4/16.2) id AA21273; Tue, 15 Oct 96 21:15:22 -0500 Received: by wave.sps.mot.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA3496; Tue, 15 Oct 96 21:31:12 -0400 Message-Id: <9610160131.AA3496@wave.sps.mot.com> Received: from ECO with "Lotus Notes Mail Gateway for SMTP" id 2FC8E108BE8A1DB3482563C5000C7AC0; Tue, 15 Oct 96 21:31:11 To: hpff-interpret From: Xiaobing Feng/NCIC Date: 16 Oct 96 10:21:34 Subject: hpff-interpret: for HPF version 2.0 X-Importance: High Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Dear Mr. / Mrs. I am a member of parallel compiler group of Peking Univ. We had written a front end of HPF version 1.0, now, we want to go on. I want to know whether the new specification( version 2.0) of HPF had been released. If it is right, please tell me how I can got it from Internet. Thanks for your help. Sincerely, Feng Xiaobing --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Wed Oct 16 01:24:55 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id BAA25985 for hpff-interpret-out; Wed, 16 Oct 1996 01:24:55 -0500 (CDT) Received: from relay-1.mail.demon.net (relay-1.mail.demon.net [158.152.1.140]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id BAA25980 for ; Wed, 16 Oct 1996 01:24:51 -0500 (CDT) Received: from post.demon.co.uk ([(null)]) by relay-1.mail.demon.net id ac17161; 16 Oct 96 7:21 BST Received: from nasoftwr.demon.co.uk ([158.152.18.126]) by relay-3.mail.demon.net id ab08960; 16 Oct 96 7:15 BST Received: from ferrari.nasoftware by nasoftwr.demon.co.uk id RAA07109; Tue, 15 Oct 1996 17:55:22 +0100 From: Dave Watson Received: by ferrari.nasoftware id AA26262; Tue, 15 Oct 96 17:55:22 BST Local-From: dave@ferrari (Dave Watson) Message-Id: <9610151655.AA26262@ferrari.nasoftware> Subject: Re: hpff-interpret: HPF: dimensioning a processor arrangement by To: David Presberg Date: Tue, 15 Oct 1996 17:55:21 +0100 (BST) Cc: hpff-interpret@cs.rice.edu In-Reply-To: <199610151513.LAA52690@theory.tc.cornell.edu> from "David Presberg" at Oct 15, 96 11:13:42 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > > > The latter issue is clearly covered by the definitions in the F90 > (soon to be F95) standard, and would hang on the status of > number_of_processors() as defined in HPF ("constant expression" > vs. "restricted expression", both of which are semantic notions, not > strictly c.f.g. general class names). Note that there are non-HPF > inquiry functions in F90 that fall in the category "constant > expression" when their arguments are appropriate, and in > "specification expression" similarly. > The non-HPF inquiry functions in F90 that fall in the category "constant expression" when their arguments are appropriate are evaluable by a compiler at compile time. The same is not true for number_of_processors(). > > If HPFF proposed to change the text of HPF 1.1, Section 5.2, page 91, > lines 39 .. 43, (quoted by Chuck Koelbel) to assert that > number_of_processors() was in the "constant expression" category per > F90, Section 7.1.6.1, much of the discussion about ARRAY declarations > would shift accordingly. And the note about that function controlling > the declared extents of COMMON arrays (why the extra issue about > SAVE?) SAVE'd objects are restricted in F90 similarly to objects in COMMON > would have to be accomodated by HPF vendors' run time systems: > they either would have the infrastructure in place to accomodate it or > not, and would vote accordingly in HPFF. (I give a talk about HPF in > which I have the aside: "HPF COMMON is not your grandfather's ...") > I agree that non-sequential COMMON in HPF is a different beast to sequential F90 common. My difficulty with accepting number_of_processors() as a constant is the interaction with the sequential aspects of F90. If HPFF asserts that number_of_processors() is in the "constant expression" category then this affects the F90 features which can currently rely on the fact that bounds are statically determinable. Allowing number_of_processors() in an initialisation-expression means that COMMON data objects and SAVE data objects are potentially no longer statically sized. This opens up "dynamic equivalence" relations since REAL c(number_of_processors()) COMMON /VARIABLE/a(number_of_processors()),b(10) EQUIVALENCE (b(1),c(1)) now becomes valid. This is, in my opinion, an unnecessary deviation from F90 since F90 is very specific about avoiding such a feature. cheers Dave Watson --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Wed Oct 16 19:03:54 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id TAA21127 for hpff-interpret-out; Wed, 16 Oct 1996 19:03:54 -0500 (CDT) Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id TAA21121 for ; Wed, 16 Oct 1996 19:03:49 -0500 (CDT) Received: from hplrss.hpl.hp.com by hplms26.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA227800627; Wed, 16 Oct 1996 17:03:48 -0700 Received: by hplrss.hpl.hp.com (1.37.109.16/15.5+ECS 3.3+HPL1.1) id AA217000703; Wed, 16 Oct 1996 17:05:03 -0700 Date: Wed, 16 Oct 1996 17:05:03 -0700 From: Rob Schreiber Message-Id: <199610170005.AA217000703@hplrss.hpl.hp.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: NEW allocatables Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Legal HPF? program prog1 !!! NEW, allocatable, size the same at every iteration: real, allocatable :: a(:) allocate (a()) !hpf$ independent, new(a) do i = 1, 100 a = i ... enddo print *, size(a) program prog2 !!! NEW, allocatable, size the same at every iteration: real, allocatable :: a(:) !hpf$ independent, new(a) do i = 1, 100 allocate (a(funct(i))) a = i ... deallocate(a) ! ??? Is this required? enddo Now, how about: program prog3 !!! NEW, pointer, size the same at every iteration: real, pointer :: a(:) allocate (a()) !hpf$ independent, new(a) do i = 1, 100 a = i ... enddo print *, size(a) program prog4 !!! NEW, pointer, size the same at every iteration: real, pointer :: a(:) !hpf$ independent, new(a) do i = 1, 100 allocate (a(funct(i))) a = i ... deallocate(a) ! ??? Is this required? enddo program prog5 !!! NEW, pointer, associated on entry real a, b pointer a; target b a => b !hpf$ independent, new(a,b) do i = 1, 100 a = i ! Must a appear in the NEW clause? ! Must b appear in the NEW clause? ! Must both a and b appear in the NEW clause? ... enddo ! what is the status of a here? if (associated(a)) print *, 'A is associated' program prog6 !!! NEW, pointer, associated on entry real a, b(100) pointer a; target b a => b(1) print *, a !hpf$ independent, new(a) do i = 1, 100 a => b(i) a = i ... enddo ! what is the status of a here? if (associated(a)) print *, 'A is associated' --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Wed Oct 16 22:46:53 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id WAA27293 for hpff-interpret-out; Wed, 16 Oct 1996 22:46:53 -0500 (CDT) Received: from [128.42.5.179] (kradak-asyn9.rice.edu [128.42.5.118]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id WAA27280; Wed, 16 Oct 1996 22:46:43 -0500 (CDT) X-Sender: chk@titan.cs.rice.edu Message-Id: In-Reply-To: <9610160131.AA3496@wave.sps.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Oct 1996 21:47:07 -0500 To: Xiaobing Feng/NCIC From: Chuck Koelbel Subject: Re: hpff-interpret: for HPF version 2.0 Cc: hpff-interpret Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Thank your for your interest. We hope that the HPF 2.0 draft will be released in a few days. Keep reading your e-mail for the announcement. Chuck Koelbel --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------