From owner-hpff Tue Jun 18 16:39:22 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id QAA24204 for hpff-out; Tue, 18 Jun 1996 16:39:22 -0500 (CDT) Date: Tue, 18 Jun 1996 16:39:22 -0500 (CDT) From: owner-hpff Message-Id: <199606182139.QAA24204@cs.rice.edu> >From: Mary E Zosel Subject: hpff: May 96 HPFF minutes High Performance Fortran Forum Meeting May 1-3, Arlington, Texas Record of Action: Mary Zosel Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@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. --------------------------------------------------------------------------- Executive Summary There were 22 people from 18 institutions present at the May 96 HPFF meeting. The group processed the first or second reading of a number of language proposals. Following summarizes the status. Details of the proposals are included in the full minutes below. Proposals passing second reading: Remove Global_LB/UB (15-0-0) Sort_UP/Down in library [in 2.0] (16-0-0) Modifications to inquiry routines (13-0-4) Extrinsic Policy (14-0-2) On Processors - no interprocedural calls (14-0-2) Proposals still in progress of second reading: New inquiry routines. Task Regions passed (12-0-4), but pending write-up. Proposals passing in first reading: Base language is Fortran (instead of F90). (21-0-1) On Processors - interprocedural interface (15-0-6) Amend C interface to be more common with ISO proposal (18 - 2 - 1) Definition of F77_LOCAL interface (11 - 2 - 4) --- Other items of note: There are three new companies on the announced product list: Thinking Machines, Transtech, and CDAC. Also Tera has been added to the "interested" category. The plan for producing the draft HPF 2.0 document was made. The next HPFF meeting is scheduled San Francisco July 10-12. The final HPFF meeting is September 18-20 (again San Francisco), with the expectation that there will be a public comment period between July and September. End of Executive Summary ____________________________ Detailed Record of Action Wednesday afternoon May 1, 96 - HPFF Subgroup Meetings. The HPFF Meeting convened Thursday AM, May 2 chaired by Ken Kennedy of Rice University. Introductions and review of voting rules took place. We are still operating under the rule that formal readings require a 2/3 vote with abstentions counting as no. The status of proposals expected for processing at the meeting was reviewed: PROPOSAL STATUS 1st 2nd group C on Jan May ck task Mar May inq updates Jan May rs group D dark corners of ptr Mar. May group E SPMD-HPF-ext. Mar May/June am/lfm Rules for extrinsics 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) reduce - simple 2 rs (D) reduce - 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 ~ For the first technical item, Mary Zosel presented the second reading of the proposal to remove GLOBAL_LB/UB from HPF 1.2 (and HPF 2.0). The original motivation for these functions is gone, and the definition in the document is resulting in cci's. The proposal passed 2nd reading 15-0-0. Carol Munroe presented the second reading of Sort_UP/Down which allow the possibility of sorting in one step. The existing library has grade-up/down which require two steps. There was some discussion about whether these should be subroutines to allow sort in place, but it was decided that functions are ok, and it is possible for the compiler to recognize A= SORT(A) as a special case. The proposal passed with an institutional vote of 16-0-0. Piyush Mehrotra presented another discussion o f Dark Corners of Pointers - A long running Day Time Soap Opera also known by the name "As the Stomach Turns". The current proposal for mapping of pointer is that: Pointers with sequential attribute may - point to targets with sequential attribute only. - allocate sequential object only. Pointer with no explicit mapping may - point to targets with no explicit mapping. - require consistency particularly across procedure boundaries. Rob asks if something declared DYNAMIC falls here - Piyush/Carl say no. Pointers with static declarations may - point to non-dynamic objects with "conforming" mapping. - allocate object with specified declaration. Pointers with dynamic attribute: - point only to targets with dynamic attribute. - can redistribute using the pointer if - point to the whole object - object is allocated through a pointer - all other pointers lose association. - range can be used to restrict what it points to. - allocation as usual. NEW: Pointers can have a transcriptive distribution. distribute * :: p(:) - this pointer can be used to point to ANY mapping. - range can be used to restrict target distribution. - (note that) cannot be used for redistribution. - allocation - compiler's choice. Rob continued discussion - pointing out that DYNAMIC is orthogonal to mapping. Rob proposed an amendment so that dynamic points only to dynamic and non-dynamic points only to non-dynamic (static). The subcommittee will fix the proposal to reflect this and come back. Carol Munroe observed that pointers without dynamic cannot be passed to routines where the arg has dynamic. ===== Back tracking --- Rob moved that SORT be part of the 2.0 standard instead of approved extensions: Seconded. The chair interprets as only 1 vote needed and the proposal passed by an institutional vote of 16-0-0. Next the vendor slide was reviewed. There are three new companies on the announced product list. It now reads: Announced Product Applied Parallel Research, CDAC, Digital, Fujitsu, Hitachi, IBM, Intel, Meiko, Motorola, NA Software, NEC, Pacific Sierra Research, The Portland Group, Inc., Thinking Machines, Transtech Announced Effort ACE, Lahey, NAG, nCube Interested Edinburgh Portable Compilers, HP, Silicon Graphics/Cray Research, Sun, Tera Note the tendency of companies that stay in the interested category, also are tending to merge. It's a dangerous place to stay. :-) ======== Rob Schreiber presented Inquiry updates: mods to HPF_ALIGNMENT, HPF_TEMPLATE, HPF_DISTRIBUTION - Removes reference to aggregate covers. - may these be called for Sequential objects? Now not for assumed_size dummy args - these things do have a mapping ... but they cause problems because these routines are libraries (instead of intrinsics) and it is non-trivial to call the library with both kinds of arguments. Straw vote about forbidding sequential in all inquiry functions: 18 - 0 - 4 There are now new outputs to HPF_DISTRIBUTION: PLB - processor lower bound PUB - processor upper bound PSTRIDE - processor stride LOW_SHADOW HIGH_SHADOW Example REAL A(10,10) !HPF$ TEMPLATE T(40,20) !HPF$ ALIGN A(I,:) WITH T(3*I+1, 2:20:2) !HPF$ DISTRIBUTE T(BLOCK, BLOCK) ONTO PROCS (4:1:-1, :) PLB = [4,1] PUB = [1,2] PSTRIDE [-1:1] Two New Inquiry Functions are proposed: Map_Array (Array,Dim) Number_Mapped(Array,Dim) Dimension A(2) !HPF$ Template T(4,8) !HPF$ Align a(I) with T(2*I, 5) !HPF$ Processors procs(2,2) !HPF$ Distribute T(Indirect ((/1,2,2,1/)), GEN_BLOCK ((/3,5/))) ONTO PROCS MAP_ARRAY (A,DIM=1) is [1,2,2,1] MAP_ARRAY (A, DIM=2) is [ 1,1,1,2,2,2,2,2] Henry points out that this is a result that can get changed by a comment. DIMENSION A(2,40) !HPF$ template t(4,8,4,16) !HPF$ align a(I,*) with T(2*I, 5,*,*) !HPF$ PROCESSORS PROCS (2,2,3) !HPF$ distribute T ( Indirect ((/2,2,1,2/)), & BLOCK ((/3,5/)), *, BLOCK) ONTO PROCS NUMBER_MAPPED (A, DIM = 1) is [1,3] NUMBER_MAPPED (A, DIM = 2) is [3,5] NUMBER_MAPPED (A, DIM = 3) is [6,6,4] There is a full write-up for the item. These are second readings. Vote on mods to the align, template, distribution functions with the first two items changes to HPF 2.0 and the new outputs part of the extended language: 13 - 0 - 3 Questions clarifying local library - they exist, but they refer to the global routines. Now on the new inquiry functions, MAP_ARRAY and NUMBER_MAPPED (for gen-block and indirect), Henry proposed an amendment to make these subroutines. After discussion, Carol seconded the amendment and proposed an improvement: call map_array (array, dim, result) where result needs to be at LEAST as big as the max size the of the returned value and does not require that the caller know exactly how big it is. Rob agreed to call this a friendly amendment. Jerry wonders if a different keyword should be used ... e.g. PROCSDIM ... to be consistent it should be PROCESSORS_DIM. What about names for the results? Could also possibly be just one subroutine with two possible results. Final result to vote on later. BREAK Mary presented the proposal for Extrinsic Policy HPFF will have a policy of formally recognizing certain extrinsic interface definitions, where the interface, and its addition to the HPF document is considered to be a service to the HPF community. Examples are language bindings to HPF or library packages. To be considered for HPFF recognition, a proposed extrinsic must demonstrate the following things. It should be noted, however, that meeting these criteria does not guarantee acceptance of a proposed interface by HPFF. conformance to HPF rules for calling extrinsics (reference) significant new functionality existing practice such as users, implementations, etc. institutional backing with evidence of ongoing support coherent documentation non-proprietary interface definition copyright goes to HPFF for interface, with permission to use (royalty free) If accepted by HPFF, then: HPFF will recognize the interface and reference it in documentation, but HPFF does not assume responsibility for the extrinsic or its interface. The sponsor of the extrinsic must continue to conform to the HPF interface rules for extrinsics. The interface HPFF approves must not change without HPFF approval. The sponsor must assume responsibility for any CCI requests concerning the extrinsic. A list of recognized extrinsic interfaces will be included in HPF documentation, with the following guidelines: There should be a single page introduction to the extrinsic which contains: the name of the extrinsic a brief abstract of functionality a brief and informal description of the interface information about platform and system availability reference and contacts for formal documentation, continued responsibility, and additional information (e.g. compiler availability). There should be about two pages with short examples of usage. A short paper with the formal definition of the interface and an informal description of the functionality of the extrinsic. To submit an extrinsic interface to HPFF for consideration, the sponsor prepares a proposal that includes: a statement of what significant new functionality is provided a description of existing practice a statement institutional backing with evidence of ongoing support a copy of the coherent documentation a copy of the text (described above) that would be included in the HPFF documentation a statement justifying the claim that the interface follows HPF conventions for calling extrinsics. If approved the sponsor then submits: a formal statement for HPFF records that the interface definition is non-proprietary and that the copyright of the interface belongs HPFF. the formal contact for CCI and continued maintenance of interface a copy of the interface documentation formatted for HPFF use, including a copy in the current document and web mark-up languages. ---- There was discussion about what is the continuing process for submitting new things - this proposal presumes that the process continues. It was decided that this should be in the document as the introduction to the appendix containing any interfaces. Question - should be generalized for interfaces like libraries: --- 13 - 0 - 3 Vote on the Policy ... Second READING - 14 - 0 - 2. Some discussion of status of our F90_LOCAL - should it become one of these? How about the proposed F77_LOCAL? There was additional discussion about our base language document - F95 or F90? Carl raised a different point - should we really say F90_LOCAL? Shouldn't it just be Fortran_LOCAL? Jerry points out that X3J3 will probably vote the recommendation that the F77 archival standard be withdrawn. Ken points out that this may make our action clear ... we should just say that our base language is Fortran. StrawPoll --- We should be based on the "current" Fortran standard. (Implication is that we change F90_LOCAL to Fortran_LOCAL.) 21 - 0 - 1 This was declared to be a first reading of this subject. BREAK FOR LUNCH - to return at 1:10. Chuck Koelbel presented the 2nd Reading - ON Proposal. In first reading, this was for approved extensions only. On gives more control to the user and recommends where operations should be executed. Resident asserts that data need not move to processors outside the "on" set. !HPF$ ON HOME (a(i)) a(i+1) = b(i) + a(i) ---- do i=1,n !HPF$ ON HOME (a(indx(i))) BEGIN a(indx(i)) = b(i) v(i) = c(indx(i)) !HPF$ END ON end do --- Do k - 1,10 !HPF$ ON HOME (X(:,k) ) DO j = 1,100 !HPF$ ON HOME (X(j,k)) y(j+1,k+1) - x(j,k) + x(j+1, k) + x(j,k+1) end do end do -------- examples with calls consider !HPF$ ON HOME (a(1:2)) call foo(a) --- subroutine foo(x) !HPF$ ENVIRONMENT :: ON HOME (x(1)) x(2) = ... key rules: - foo must have explicit interface in caller - foo's interface must include declarative ON - foo's ON set must be a subset of caller's ON set - DISTRIBUTE and ALIGN in foo: locals and dummies: mapped to foo's ON set Globals: may be mapped anywhere ALLOCATABLES: mapped to ON set of ALLOCATE Discussion - particularly about the assumptions about unmapped dummies. This was referred back to subgroup to work out more details. --- Chuck next presented the proposal for RESIDENT. !HPF$ ON HOME (X(k)), RESIDENT (X(indx(k)) x(k) = x(indx(k)) + y(indx(k)) !HPF$ ALIGN x(i) WITH y(i) DO i=1,n !HPF$ ON HOME (indx1(i)) BEGIN !HPF$ RESIDENT( x(n1)) BEGIN n1 = indx(i) n2 = indx2(i) tmp = y(n1) - y(n2) x(n1) = x(n1) + tmp x(n2) = x(n2) - tmp !HPF$ END RESIDENT !HPF$ END ON END DO Inter procedural Issues: Does the compiler know which processors should execute FOO? Yes from the declarative ON. Can the compiler allocate data? Yes, local data in FOO must be mapped on executing processors. ALLOCATE must map to executing processors. Previously allocated data (globals, ALLOCATABLES) were local when memory was allocated. Remapping must map from executing processors to executing processors Can the compiler access data? As well as it ever could. Should dummies be resident by construction? - straw proposal 14 - 0 - 7 Jaspal Subhlok presented the current TASK REGIONS proposal: !HPF$ begin task regions do I - 1,n ! a task regions is an assertion (disclosure about code in region) !HPF$ ON HOME (P91:4)) ! code directed to executed ON a processors subset can only access RESIDENT data call colffts(a1) !HPF$ endon a2 = a1 ! No two ON blocks executing on non-identical processor subsets can have conflicting I/O !HPF$ ON home (p(5,8) call rowffts(s2)) !HPF$ endon enddo !HPF$ end task regions ---- Execution MODEL / IMPLEMENTATION Same code is generated as without task region, except: - non executing processors skip ON blocks completely - synchronizations / barriers inside an ON block are restricted to the subset Task Parallelism Issues nesting TASK REGIONS and Ons is allowed exits from task regions are allowed, but may inhibit parallelism (exit from an ON is of course illegal) Implementation should replicate computations involving replicated variables (This is a good idea in general in HPF) Async message passing can exploit more task parallelism than synchronous in barrier-based models. example TASK REGION while (true) on HOME (p1) done1 = read(a1) if (!done1) fft1(a1) end on done = done1 !potential barrier if (done) exit a2 =a1 on home (p2) fft2(a2) end on a3 = a2 on home (p3) fft3(a3) end on end while end task region The difference from what Chuck presented at the last meeting is on I/O. This has a tighter restriction. Vote with the understanding that if documentese doesn't appear tomorrow - it is resinded ... 2nd reading ... 12 - 0 - 4 (as an approved extension) BREAK FOR SUBGROUP MEETINGS FRIDAY MORNING Mary presented the document plan In the interest of time - we will abandon the idea of producing a 1.2 document, but we will use the text prepared for this document as the basis for generating our new 2.0 document. The time schedule for producing the 2.0 document follows. May 3: Chuck sends out a file with the 1.2 base files (minus the library) May 3: Chuck initializes an HPFF_DOC email list with instructions for how to subscribe. Before May 10: Raw text pasted together in the order of the chapters given below is due to Chuck. This text may or maynot be in latex. Chuck will merge and distribute a "raw" document as our starting point. May 13-May 22 - Chapter writers produce latex in roughly hpf-ese for each chapter. Before May 22: Latex with in roughly HPF-ese for each chapter is due to Chuck. Things like cross-references will be missing. May 23 - Chuck will post the first "latex" draft of the document. May 24-June 7 back-up readers, volunteer readers, sweepers go over text and send in comments to hpff_doc. Each comment should reference the chapter in the subject line. June 7-June 21 Chapter editors iterate to improve and incorporate comments. Comments can also continue - but may not make it into the revised text. By June 21 - Send updates to Chuck. June 24 - Chuck reposts document. An "alpha" version of the document also sent to wider audience to request early help in fixing problems in the document before it goes for formal public comment. June 27 - If some serious problems are noted with the June 24 version - fixes due by this time. Draft to Theresa for printing by June 28. (This timing recognizes that between the US holiday the following week, and the Vienna workshop, very few people will be around, and Chuck will not be available to issue a revised document, and that a few days are required for duplications / shipping. July 10-12 - Final Names of the primary writing team, and back-up readers for each section are limited. These are people who commit to input by the dates given and Mary will contact directly to nag about their contributions. For each chapter a primary writing team has been assigned, along with other names designated as readers. It should be understood that anyone is welcome to read an comment on any section. In addition, a "sweep team" has been named - for a group who will do a pass across the entire document - looking for more global issues that might have "slipped through cracks": did CCI's get in? did all the proposals get in? Did the appropriate material from 1.1 get included or removed? Is the division between 2.0 and Extended features correct? DOCUMENT OUTLINE and NAMES Section I Introduction Chapter 0: Front, ack, etc writer: Mary reader: Chuck Chapter 1: Overview - terms and concepts - new document/language structure, Fortran language base, F95 features, HPF 1.1 deletions, etc. writer: David and Carl reader: Bob, Rob, Chuck, Jerry Section II HPF 2.0 Chapter 2: Mappings - distribute, align, sequence, some of pointer. Material from most of v1.1 chapter 3 and some of chapter 7. writer: Piyush, Carl, GLS reader: Saday, Guy R. Chapter 3: Mapping across Subprogram Interface. Material from v1.1 chapters 3 and 7. writer/reader - same as chapter 2. Chapter 4: Independent and Reduce writer: Chuck reader: Rob and Jay Chapter 5: HPF Library (plus sort-up and sort-down) writer: Rob reader: Carol Chapter 6: Extrinsics writer: David reader: Mary Chapter 7: Portability and Efficiency Issues (forall examples) writer: Andy, Chuck reader: Larry, Carl, Henry, Guy R. Section III Extended Features Chapter 8: More mappings (and related subprogram interface issues){should this be two chapters as in Section II?} GenBlock, indirect, range, shadow, subsets, derived type, more on pointers. writer: Piyush, Carl reader: Saday, Guy R. Chapter 9: ON, TASK, RESIDENT writer: Chuck, Jaspal reader: Jay Chapter 10: New Library - generalized transpose, extended inquiries, new mappings. writer: Rob reader: Henry Chapter 11: Async I/O writer: Larry reader: Alok Chapter 12: HPF_LOCAL writer: David reader: Carl, Carol, Saday Chapter 13: HPF_SERIAL writer: David reader: Carl, Carol, Saday Chapter 14: PROVISIONAL TEXT - F77_LOCAL (don't really know where and if this goes yet). writer: Carol reader: ? Chapter 15: C Interoperability writer: Henry and Andy reader: Scott, Jerry Section IV Appendixes A - BNF (GLS) B - Extrinsic Extrinsics - (policy, mechanism, HPF_CRAFT) writer: Mary, Andy reader: Bob C- Subset writer: Mary reader: Carol Glossary and Bibliography later. PLEASE - Chapter writers - note those features that should be defined in the glossary and put the appropriate latex on the key places they are used. Sweep Team: Piyush, Carol, Henry, Rob, Mary Meeting date discussion Move date to July 10-12 SF meetings will start about 10am and end by 10am Friday We should try for some external readers prior to this meeting. ---------- Chuck revisited ON proposal. Simplifications: Introduce the idea of "active processor set" the set of processors that are executing the processors in the dynamically nearest enclosing ON Do not require declarative ON in called procedures instead the call (dynamically) inherits the active processor set of the caller the call is performed by the caller's ON clause processors Clean up dark corners unmapped local variables - always stored on active processors other unmapped variables - cannot assert RESIDENT Processor subsets - need not be regular sections Explicit Data Mapping Intuition is still the same PROCESSORS, ACTIVE:: P(ACTIVE_NUMBER_OF_PROCESSORS()) allows references to the active processor set use P later in ONTO clauses, for example DISTRIBUTE No ONTO: Compiler chooses processors from active set With ONTO: locals must map to active processor set (semantic restriction) ALLOCATE of mapped data put data onto ALLOCATE's active processor set ALIGN Relevant elements of align-target must be on active processor set REDISTRIBUTE and REALIGN Active processors set must include old and new data homes Rob points it should be number_of_active_processors - but this is a pretty long-winded identifier. This replaces the use of number_of_ processors - in almost all cases, except for common. Consider in two parts: Non - interprocedural stuff - second reading - including amendment for ON PROCESSORS ... 14 - 0 - 2 First reading interprocedural definition - 15 - 0 - 6 (There will be something in the draft document.) -------- The remaining inquiry functions were postponed until July meeting. ------- TASK provisionally passed missing the text. ------- POINTERS - first 2 points the same as presented yesterday: pointers with sequential attribute pointer with no explicit mapping AND propose these go into 2.0 pointers with explicit mapping point to targets iff they have explicit conforming mapping allocate object of the specified mapping pointers with transcriptive mapping pointer :: p(:) distribute * :: p point to targets with any explicit mappings range can be used to restrict on allocation - compiler chooses In cases 3 and 4 if the pointer also has the dynamic attribute point to targets iff they have the dynamic attribute range can be used to restrict allocation with usual restrictions redistribution with restriction First reading of conforming mapping: two objects have a conforming mapping iff the corresponding elements are assigned to the same abstract processor. There was some discussion about what this means wrt partially specified distributions. straw poll - can conforming have under specification? 10 - 0 - 9 straw poll - in favor of a definition along this line 16 - 0 - 4 Second reading of items 1 and 2 for pointer (into 2.0): 15 - 0 - 0 Second reading of items 3 and 4 for pointers, to go into approved extensions: 13 - 0 - 2 Larry meadows moved that item 3 go into 2.0. The vendors were consulted before voting - with a formal vote of 14-0-0. Larry Meadows moved that that with the exception of dynamic and range that item 4 go into 2.0. Again, after vendor consultation the vote was 8 - 0 - 7, so the motion fails. So pointers with transcriptive mappings goes in approved extensions. BREAK Henry Zongaro and Jerry Wagener: Report from C interoperability .... Reviewed 2 proposals. EXAMPLE - char * coo (int *, char [], struct *s) ptr to int, char array, and ptr to struct struct s { int P, double q[10] }; There are deficiencies in both - e.g. ** double indirection HPFF proposal: module vogs type s integer :: p real :: o(10) end type interface extrinsic (c) function coo (A,B,C) NAME ('Coo') character (*), map_to(char[]) :: c00 integer, intent (out), map_to(int) :: A character (*), intent (inout), map_to(char[]):: B type (s), intent (in), map_to (int, double []):: C end function c00 end interface contains subroutine Foo1(J.K) integer, intent (in) :: j type (s), intent (out) : k character (*) PROGRAM Zxy use vogs integer ::x real :: y character (80) :: z type (s) ;:: ss real MODULE DEF_DATA_TYPES USE ISO_C_KINDS; USE IOS_C_STRINGS TYPE DT integer :: I; (KIND (... ) endtype DT type, BIND (C) :: DT_C integer (C_INT_KI) :: I; REAL (C_DOUBLE_KR) :: ARR (10) end type DT_C END MODULE DEF_DATA_TYPES PROGRAM P USE DEF_DATA_TYPES INTERFACE BIND (C, NAME = 'Coo') FUNCTION coo (I,C,s) USE DEF_DATA_TYPES TYPES (C_CHAR_STRING):: coo INTEGER (C_int_ki) Amendment to existing proposal: change the c type names have kind type parameters in the map-to use intent out to convey address-of extend map_to to structures Finish the details of the amendment ... at the next meeting .... 18 - 2 - 1. To be continued at the next meeting Carol Munroe: >From the subgroup that discussed the Fortran issues. The impact of a change of the base language on the document should be minimal. Basically, the rule numbers are ok. It would be nice if we could have some appendix with formal definition of features we use - and we could shorten what we have in the document. The name of F90_LOCAL should be changed to Fortran_LOCAL. Carol then presented an F77_LOCAL proposal. The motivation is to meet the needs of two groups of users: group A - those wanting convenient interface to f77 library subroutines directly; group B those wishing to do low-level F77 programming plus message passing with local portions of globally distributed arrays with no remapping - in place, complete with complex layouts, shadow widths, etc. Provision for array passing: group A MAP_TO(F77_ARRAY) or PASS(F77_ARRAY) group B MAP_TO (NO_CHANGE) or PASS (NO_CHANGE) PASS (DESCRIPTOR) - if descriptor handle is needed for local for local inquiry functions. In the subgroup, several votes were taken: vote: minimalist version with just F77 keyword - 3-2-1 vote: should any F77_LOCAL interface provide an option to pass distributed arrays and make the local portions contiguous (sequence associated)? vote 6 - 0 - 0 should any F77)Local interface allow a way to pass local portions distribution? Subgroup recommends that we go for a recognized interface like HPF_CRAFT ... 4 - 1 - 1 First reading: there should be a version of F77_local - as simple as possible. 11 - 2 - 4 ------- HPCN report - Ken gave two talks at HPCN. There is good interest in Europe. HPF is being tried on a variety of applications, and there was a general positive reaction to our extensions. We should expect an active set of comments on what we are proposing. There is a lot of interest in ON and irregular mappings. Larry reported a surprising amount of interest (on the exhibit floor) from Eastern Europe, especially Poland. Guy Robinson reminded the group about the HPF meeting in Vienna in the first week of July. =========================================== As of the end of the meeting, the proposal status is: 1st 2nd group E SPMD-HPF-ext. Mar July am/lfm Base language Fortran (not F90) May July Amended C interface May July hz/jw F77_LOCAL ext interface May July cm group D dark corners of ptr Mar. May group C on - interproc May July ck task write-up Mar July inq additions Jan July rs DONE - (C) async ext lm (C) gen transpose ext rs (C) inq updates ext rs (C) task regions ext js (C) on - {no calls} ext ck (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 ~ (E)Elim. GLOBAL_LB/UB 1.2/2.0 mz New Sort functions 2.0 cm Rules for extrinsics 2 mz ------------- The next HPFF meeting is scheduled San Francisco July 10-12. The final HPFF meeting is September 18-20 (again San Francisco), with the expectation that there will be a public comment period between July and September. ------------------------------------------------------------- May Attendance: Robert Babb u. of Denver babb@cs.du.edu Siegfried Benkner Univ. of Vienna sigi@par.univie.ac.at Jay Boisseau SDSC boisseau@sdsc.edu Bob Boland LANL wrb@lanl.gov Alok Choudhary Syracuse U. choudhar@cat.syr.edu Ken Kennedy Rice U./CRPC ken@rice.edu Charles Koelbel Rice U. chk@cs.rice.edu David Loveman Digital loveman@msbcs.enet.dec.com Larry Meadows The Portland Group lfm@pgroup.com Piyush Mehrotra ICASE pm@icase.edu Carol Munroe Thinking Machines munroe@think.com Carl Offner Digitalx offner@hpc.pko.dec.com Guy Robinson University of Vienna robinson@vcpc.univie.ac.at P. Sadayappan Ohio State University saday@cis.ohio-state.edu Joel Saltz U. of Maryland saltz@cs.umd.edu Rob Schreiber HP schreiber@hplpp3.hpl.hp.com Jaspal Subhlok Carnegie Mellon jass@cs.cmu.edu Manuel Ujaldon U. of Maryland ujaldon@cs.umd.edu Arun Venkatachar Louisiana St. Univ. arun@ee.lsu.edu Jerry Wagener U. of Oklahoma jwagener@cs.ou.edu Henry Zongaro IBM Canada zongaro@vnet.ibm.com Mary Zosel LLNL zosel@llnl.gov --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Mon Jun 24 10:24:11 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA28039 for hpff-out; Mon, 24 Jun 1996 10:24:11 -0500 (CDT) Received: from mail1.cern.ch (mail1.cern.ch [137.138.128.19]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id KAA28027 for ; Mon, 24 Jun 1996 10:24:03 -0500 (CDT) Received: from sp054 (sp054.cern.ch) by mail1.cern.ch with SMTP id AA15624 (5.67b8+/IDA-1.5 for ); Mon, 24 Jun 1996 17:22:15 +0200 Date: Mon, 24 Jun 1996 17:22:14 +0200 (METDST) From: Michael Metcalf X-Sender: metcalf@sp054 To: F-mail , hpff@cs.rice.edu, sc22wg5@dkuug.dk Subject: hpff: Announcing: "The F Programming Language" Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@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. --------------------------------------------------------------------------- Announcing the first book on the F programming language ------------------------------------------------------- "The F programming Language", by Michael Metcalf and John Reid, Oxford University Press, Oxford and New York, 1996, ISBN 0-19-850026-2, (about $US30 or 16.95 pounds sterling). The F programming language is a dramatic new development in scientific programming. Building on the well-established strengths of the Fortran family of languages, it is carefully crafted to be both safe and regular, whilst retaining the enormously powerful numerical capabilities of its parent language, Fortran 90, as well as its data abstraction capability. Thus, an array syntax becomes available as part of a medium-size, widely-available language for the first time. In this respect, the language is clearly superior to older ones such as Pascal, C, and Basic. F is ideally suited for teaching as a first programming language, and provides a smooth path into both Fortran 90 and High Performance Fortran (it is a subset of both). In the absence of a formal standard for F, this book is the defining document for the language, setting out the complete syntax and semantics of the language in a readable but thorough way. It is essential reading for all F practitioners. Compilers for F are available from Imagine1 for Windows 95, Linux and some Unix platforms, with Windows NT, Macintosh PowerPC and 68K families coming shortly. The compilers are based on technology from Absoft, Fujitsu, and NAG. For details see http://www.imagine1.com/imagine1 or contact info@imagine1.com. Table of Contents: 1. Why F? . . . . . . . . . . . . . . . . 1 2. Language elements . . . . . . . . . 7 3. Expressions and assignments . . . . 29 4. Control constructs . . . . . . . . 49 5. Program units and procedures . . . 61 6. Array features . . . . . . . . . . 89 7. Specification statements . . . . . 113 8. Intrinsic procedures . . . . . . . 131 9. Data transfer . . . . . . . . . . . 151 10. Operations on external files . . . 175 Appendix A. Intrinsic procedures . . . 185 Appendix B. The statements of F . . . . 191 Appendix C. Diffences from Fortran 90 . 195 Appendix D. Pointer example . . . . . 201 Appendix E. The terms of F . . . . . . 211 Appendix F. Solutions to exercises . . 221 Index . . . . . . . . . . . . . . . . . 233 Michael Metcalf works at CERN, Geneva. He is the author of a range of publications, including the books "Effective Fortran 77" and "Fortran 90/95 Explained" (with John Reid) (Oxford University Press), and "Fortran Optimization" (Academic Press). He was Editor of the Fortran 90 standard. John Reid works for the Rutherford Appleton Laboratory and is well known as a numerical analyst; he is a co-author of "Direct Methods for Sparse Matrices" and "Fortran 90/95 Explained" (Oxford University Press). He served as Secretary of X3J3 and played a leading role in the development of Fortran 90. Ordering information: 1) N. America: Order Department, Monday-Friday, 8:15am-5:00pm (EST) Phone: 1-800-451-7556 Fax: 1-919-677-1303 Post: Order Department Oxford University Press 2001 Evans Road Cary, NC 27513 E-mail: orders@oup-usa.org WWW: http://www.oup-usa.org/ 2) UK: send order and payment to: CWO Department, OUP, FREEPOST NH 4051, Corby, Northants NN18 9BR - no stamp required Phone: with a credit card, the 24-hour credit card hotline is +44 (0)1536 454534 Postage and packing for UK orders: - under #20 - add #2.06, over #20 - add #3.53, over #50 - add #4.70. WWW: http://www.oup.co.uk/ 3) Eire, Europe, and the rest of the world, send order and payment to: CWO Dept, OUP, Saxon Way West, Corby, Northants NN18 9ES, UK Fax: credit card sales: +44 1536 746337 Postage and packing for non-UK orders: add 10% of the total price of the books. 4) Imagine1 11930 Menaul NE, Suite 106 Albuquerque, NM 87112 Toll free phone number: 1 888 323 1758. See also Imagine1's e-mail address and WWW URL above. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Sat Jun 29 16:42:25 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id QAA03563 for hpff-out; Sat, 29 Jun 1996 16:42:25 -0500 (CDT) Received: from antares.mcs.anl.gov (mcs.anl.gov [140.221.9.6]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id QAA03556 for ; Sat, 29 Jun 1996 16:42:21 -0500 (CDT) Received: from itf-pc.mcs.anl.gov (sava.slip.mcs.anl.gov [140.221.10.108]) by antares.mcs.anl.gov (8.6.10/8.6.10) with SMTP id QAA21513 for ; Sat, 29 Jun 1996 16:42:17 -0500 Message-Id: <2.2.32.19960629214206.0070feb4@mcs.anl.gov> X-Sender: itf@mcs.anl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 29 Jun 1996 16:42:06 -0500 To: hpff@cs.rice.edu From: Ian Foster Subject: hpff: HPF/MPI Info Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@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. --------------------------------------------------------------------------- Hi, A number of you have expressed interest in our work on an HPF binding for MPI. Hence, I wanted to let you know that two papers describing this work are now available at http://www.mcs.anl.gov/fortran-m/ Ian Foster. ---------------------------------------------------------- Ian Foster Tel: 708 252 4619 Mathematics & Computer Science Fax: 708 252 5986 Argonne National Laboratory Argonne, IL 60439 http://www.mcs.anl.gov/home/foster --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------