From chk@erato.cs.rice.edu Mon Mar 16 13:05:31 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA13184); Mon, 16 Mar 92 13:05:31 CST Received: from localhost.cs.rice.edu by erato.cs.rice.edu (AA13037); Mon, 16 Mar 92 13:05:30 CST Message-Id: <9203161905.AA13037@erato.cs.rice.edu> To: hpff-f90@erato.cs.rice.edu Word-Of-The-Day: roustabout : (n) 1. a dock worker 2. a laborer in an oil field or refinery 3. a circus worker with a variety of jobs Subject: Welcome to Working Group 1! Date: Mon, 16 Mar 92 13:05:29 -0600 From: chk@erato.cs.rice.edu If you are receiving this message, then you are on the mailing list for working group 1. This group is charged with discussing Fortran 90 issues (particularly storage association) arising in High Performance Fortran. Chuck From schreibr@riacs.edu Mon Mar 16 13:15:19 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA13471); Mon, 16 Mar 92 13:15:19 CST Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA29082; Mon, 16 Mar 92 11:15:18 PST Received: by thor.riacs.edu (4.1/2.0N) id AA23483; Mon, 16 Mar 92 11:14:58 PST Message-Id: <9203161914.AA23483@thor.riacs.edu> Date: Mon, 16 Mar 92 11:14:58 PST From: Rob Schreiber To: hpff-f90@cs.rice.edu Subject: Meeting March 31. Dear Hpff-f90 subcommittee, Please let me know if you are coming to the Meeting here on March 31. I will send directions later, and info on a nearby motel for Vince John, Dave, and Rex. Rob From schreibr@riacs.edu Tue Mar 17 10:37:35 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA04417); Tue, 17 Mar 92 10:37:35 CST Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA17751; Tue, 17 Mar 92 08:37:33 PST Received: by thor.riacs.edu (4.1/2.0N) id AA23598; Tue, 17 Mar 92 08:37:13 PST Message-Id: <9203171637.AA23598@thor.riacs.edu> Date: Tue, 17 Mar 92 08:37:13 PST From: Rob Schreiber To: hpff-f90@cs.rice.edu Subject: Motel Info Dear HPFF-F90 Subcommittee, For the meeting here on March 31, please call The American Inn at 415/961-6720 if you need a reservation; ask for Joanne. The meeting will be held At the NASA Ames Research Center, building 269, room 179. Mary, is 8:30 too early? Directions: From the American Inn, which is on El Camino Real in Mountain View: take El Camino East (Left out of the Inn) one block. Make a left on Castro. Take Castro to the Moffett Fiel Main Gate. See below. From the North: Take US 101 towards San Jose. Exit at Moffett Field. From the South: Take US 101 towards San Francisco. Exit at Moffett Field. From the Moffett Main Gate. GO LEFT BEFORE THE MAIN GATE. After 150 yards or so, turn right into the NASA VISITOR BADGING building, a low, grey rectangle. There they will give you a visitor's badge, map of the base, directions to building 269, and a vehicle pass. Rob From zosel@phoenix.ocf.llnl.gov Tue Mar 17 11:53:09 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA06690); Tue, 17 Mar 92 11:53:09 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA02159; Tue, 17 Mar 92 09:53:07 -0800 Date: Tue, 17 Mar 92 09:53:07 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9203171753.AA02159@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: binding wars :-) Group 1 --- I finally got around to reading some email from X3H5 and thought you might be interested in this ... a variation of our discussion played in the X3H5 arena where they are now preparing specific bindings for PCF. (I guess my personal sympathies lie a bit with the pro-F90 person in this one, because for PCF, there are things which are somewhat clumsy in F77 and would have much cleaner solutions in F90. It appears that X3H5 (or at least its chair) has adopted the stand that they will produce an F77 binding and then an F90 binding which is a compatible superset of the F77 binding. You might keep this in mind when reviewing F90. Will this become an issue for us? -mary- ------ ------ ----- Date: Fri, 6 Mar 1992 12:34:58 -0600 From: Bruce Leasure To: x3h5@cs.orst.edu Subject: X3H5 NegComments Title: Negative Comments on Fortran 77 Binding Date: March 6, 1992 Author: Bruce Leasure Document: X3H5/92-0091-A Question: The project proposal to construct a Fortran 77 binding as documented in X3H5/90-0008-B is approved and should be forwarded to X3/SPARC for assignment to X3H5. The negative vote was from: Keith.Bierman@Eng.Sun.COM Brief History: A rough Fortran 77 binding exists in X3H5 documents. This binding was developed to make sure that a binding could be developed from the approved project to develop "The Parallel Processing Model for High Level Programming Languages". The "justification" and "lifetime" sections of the project proposal have been updated to reflect the thoughts of X3H5 on this negative vote. All lines that begin with >> are about the negative vote. All comments from the negative ballot, and another electronic communication are included. Comments from the Negative Ballot: >> As previously discussed, there is no change to this proposal that >> would change our No vote to a Yes. Thus, this vote is an unalterable negative ballot. >> Fortran '77 (X3.9-1978) has been retained as an archival standard >> only. No changes to the language it represents should be considered by >> ANSI. >> Doing '77 "bindings" constrains the '90 work in ways which are not >> acceptable. Doing it "both ways" represents a major problem for users >> of the standard(s). Fortran 90 identifies (in section 1.6 of the ISO standard) two classes of outmoded features in Fortran 77: deleted features and obsolescent features. No Fortran 77 features were placed in the deleted features list, and nine features were placed in the obsolescent features list. Here is the complete list (from Annex B): arithmetic IF real or double precision DO loop index shared DO termination & termination on other than CONTINUE branching to an ENDIF from outside the Block IF alternate return PAUSE statement ASSIGN and assigned GOTO statements assigned FORMAT specifiers Hollerith edit descriptor All other features of Fortran 77 are included in Fortran 90 without comment. X3H5 concludes that all features of Fortran 90 are "equal", except for the ones identified by Fortran 90 as outmoded. As a builder of a binding to Fortran 90, it seems unreasonable to choose only one of the methods of doing something as a binding target if Fortran 90 provided several equivalent features. X3H5 should not select a "preferred set" of features that might control the future of Fortran 90. This means that X3H5 must provide a binding to ALL of the non-outmoded features of Fortran 90. This includes almost all of Fortran 77. Hence, a Fortran 77 binding is an obvious intermediate stage. >> In addition, it may very well result in undue friction with our >> European counterparts; certainly the early comments from them lead >> one to believe this. The project proposal clearly states in the "Lifetime" section that the Fortran 77 binding will be superseded by the Fortran 90 binding. This is a revision to the project proposal that was made in response to this point. >> Any one of these would be sufficient grounds. Comments from the an Earlier Electronic Message: >> Reasons why a X3H5 binding to X3.9-1978 (hereinafter spelled f77) is a >> bad idea: >> 1) f77 has been replaced by ISO 1539:1991 (f90 in what follows) in >> the International arena. ANSI adoption will certainly take >> place before X3H5 can ship a finished standard. True. But Fortran 77 implementations will dominate the user community for the next several years. >> 2) f90 provides a far superior base for X3H5 to bind to. True. X3H5 is working on a complete Fortran 90 binding (see companion project proposal). The Fortran 77 binding is an obvious intermediate step. See earlier response for more information on this point. >> 3) X3H5 will want to (as evidenced by discussion in committee, >> and common sense) have a f90 binding that is compatible with >> the proposed f77 binding. This constrains the f90 binding >> in a variety of nasty ways. This will result in a suboptimal >> f90 binding. X3H5 does want a Fortran 90 binding that is a superset of the Fortran 77 binding. But, since many of the new features in Fortran 90 have orthogonal syntax to Fortran 77, there is no problem with making "bad" choices in the Fortran 77 part that will make the binding to the new features in Fortran 90 suboptimal. >> 4) A pure f90 binding could be much closer to a C/C++ bindings. >> SCOMMON is an "evil" concept which maps poorly onto nearly >> all computer languages. In f77 there was no standard way, other >> than COMMON, to group variables together; so the PCF decision >> to create SCOMMON was a suitable one. But f90, C, C++ >> (and other languages) have superior mechanisms which can and should >> be exploited. Interlanguage calling is important, so we will have >> to make sure that if there is an SCOMMON, that there are >> ways to "spell" it for each language. Fortran 90 contains COMMON as a non-outmoded feature. Thus a binding of the X3H5 to Fortran 90 must explain how to deal with COMMON, just as it must explain how to deal with MODULEs. The important point of COMMON is not that it groups variables together, but rather that addressability can be established to a COMMON block with any action or knowledge from the caller. A similar characteristic with PUBLIC objects in a MODULE. >> 5) The style of X3H5's proposed bindings, language extensions, >> ensures that considerable work will be required to compiler >> front ends. Some of the proposed features may even require >> considerable linker work. Compiler writers are, and should be, >> focused on building f90 compilers at this point. Creating >> a f77 binding first, ensures that effort will have to be >> put on f77/X3H5 *first* for competitive reasons. This will >> help retard the acceptance of f90 which seems like an anti-social >> act for one X3 group to work to retard the work of anothers. The work to adjust the syntax of the compiler front-ends is relatively minor compared to the effort to support parallelism. Compiler builders for parallel machines already have much of the syntax/semantics suggested by early drafts of this binding. X3H5 makes no comments on how compiler builders should be spending their time. >> 6) It is my understanding that WG5 is interested in evolution >> of Fortran and collateral standards (the varying length string >> standard module, for example). Various WG5 members have made >> it quite clear that a f77 binding will irritate them. If our >> adoption of it forced us to have an upward compatible >> binding, they will almost certainly arrange for there to be >> a "pure" f90 "binding". We do not need another war with ISO. X3H5 is planning on producing Fortran 90 binding that is a superset of the Fortran 77 binding. X3H5 believes that this is the ONLY viable course because essentially all of Fortran 77 is contained in Fortran 90. Earlier responses have explained this position in more detail. >> 7) It will be hard enough to do C and f90 bindings in a timely >> fashion. We do not seem to have a large enough membership to craft >> three bindings plus a model. In addition, focusing on f77 >> as a base has resulted in our going down several paths that >> are probably mistakes in f90 (data sharing, scoping, etc. rules >> are quite different). X3H5 believes that building a Fortran 90 is not any less work than building a Fortran 77 binding and then building a Fortran 90 binding. In fact, it is the belief of the majority of X3H5 that constructing the Fortran 90 binding in two steps will result in the existence of a complete Fortran 90 binding sooner. >> A year or so back, perhaps I might have merely abstained. Four years >> ago, this would have been a fine proposal. However, to accept this >> proposal at this stage (f90 being done, and in interpretation phase) >> seems to me to be a grave mistake for vendors, and in the long term >> for users. Users will benefit only if quality implementations are >> forthcoming, and the resulting code is actually portable. This can >> only happen if we solve the right problems, in at least tolerable >> ways, and get "buy in" from all of the players. An f77 binding serves >> to minimize the long term chances of success on nearly all fronts. Clearly, a Fortran 77 binding can be produced before a Fortran 90 binding. This means that compiler builders can support a STANDARD, and users can start to experience the standard sooner. The feedback that comes from this early activity will allow X3H5 to reexamine issues as necessary, producing a stronger Fortran 90 binding than if there was no Fortran 77 binding. From zosel@phoenix.ocf.llnl.gov Tue Mar 17 12:10:35 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA07022); Tue, 17 Mar 92 12:10:35 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA02585; Tue, 17 Mar 92 10:10:34 -0800 Date: Tue, 17 Mar 92 10:10:34 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9203171810.AA02585@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: meeting Group 1 Rob prepared the instructions below for our March 31 meeting. Rob has offered to organize dinner out together that evening if people want to stay. I've done a minor edit to change the start time to 9AM. -mary- --- Dear HPFF-F90 Subcommittee, For the meeting here on March 31, please call The American Inn if you need a hotel. (phone 415/961-6720) ask for Joanne. The meeting will be held At the NASA Ames Research Center, building 269, room 179. Plan to start at 9:00 Directions: >From the American Inn, which is on El Camino Real in Mountain View: take El Camino East (Left out of the Inn) one block. Make a left on Castro. Take Castro to the Moffett Fiel Main Gate. See below. >From the North: Take US 101 towards San Jose. Exit at Moffett Field. >From the South: Take US 101 towards San Francisco. Exit at Moffett Field. >From the Moffett Main Gate. GO LEFT BEFORE THE MAIN GATE. After 150 yards or so, turn right into the NASA VISITOR BADGING building, a low, grey rectangle. There they will give you a visitor's badge, map of the base, directions to building 269, and a vehicle pass. From chk@erato.cs.rice.edu Tue Mar 24 16:19:01 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA25336); Tue, 24 Mar 92 16:19:01 CST Received: from localhost.cs.rice.edu by erato.cs.rice.edu (AA17493); Tue, 24 Mar 92 16:18:59 CST Message-Id: <9203242218.AA17493@erato.cs.rice.edu> To: hpff-f90@erato.cs.rice.edu Subject: [knobe@ksr.com: Re: March HPFF minutes] Date: Tue, 24 Mar 92 16:18:59 -0600 From: chk@erato.cs.rice.edu ------- Forwarded Message Date: Tue, 24 Mar 92 16:23:53 EST From: knobe@ksr.com To: chk@cs.rice.edu Subject: Re: March HPFF minutes Cc: knobe@ksr.com Chuck, I don't have the time to attend the HPFF meetings, so I really appreciate the minutes you've distributed. On the question of polling users about Fortran 90. I make at least a couple of presentations to different customers every week. I always ask them about this, because I accept that KSR will do Fortran 90 some day, but I need more information in order to pick the day. I suspect that I have conducted a more conscientious poll of people who really do use parallel machines and intend to buy more parallel machines than anybody else. These are not views based on my talking to implementors or language lawyers or reading magazines. I get very consistent answers to my questions. Just about everybody really likes the array syntax. Some people really want the features that require passing dope vectors, some don't need it. Probably a 50-50 split. Just about everybody agrees that they can easily live without the rest of the language. They don't require modules, pointers, structured types, etc. They all require allocateable arrays. The talk about pointers never has anything to do with Fortran 90 pointers. It has to do with Cray pointers. Most people are willing to live without Cray pointers if they have other mechanisms for allocating storage. I haven't done any polling on storage association. Since my machine provides a shared memory model, it's not an issue for me. This may also bias my view, but I'm rather horrified by everybody's willingness to drop storage association. This is an extremely common programming practice. It's the way that Fortran programmers who are good conscientious citizens pass columns of arrays. If you look at any of the big software packages (e.g., NASTRAN at 850,000 lines) they all take advantage of storage association. Compilers that don't continue to provide support for this feature will leave behind a very large fraction of the existing code base. I believe that the major value Fortran brings to the marketplace is the existing code base. Thanks again for the great minutes. Bruce ------- End of Forwarded Message From zosel@phoenix.ocf.llnl.gov Thu Apr 2 10:38:54 1992 Received: from phoenix.ocf.llnl.gov ([134.9.48.6]) by cs.rice.edu (AA00720); Thu, 2 Apr 92 10:38:54 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA26896; Thu, 2 Apr 92 08:38:53 -0800 Date: Thu, 2 Apr 92 08:38:53 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9204021638.AA26896@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: survey Group 1 FYI --- I sent the following survey out to a mailing list that probably hits people at about 150 CRI sites, asking them to send email back to me and Tom MacDonald. ... Following the survey is the first response back - an excerpt of a message from EPFL in Switzerland. -mary- ---- survey sent ---- Long Message - requesting input from users at your site who are interested in writing high performance Fortran applications, especially those looking toward highly parallel machine and still wanting portability. There will be discussion of this at CUG. But input from users at your site is solicited, even if you will not be in Berlin. Send email to zosel@llnl.gov and tam@cray.com {Don't just reply to unicos-l}. ------- ------- Background: A group is currently meeting to discuss the definition of some standard language extensions for "High Performance Fortran" - inspired by the Fortran D project at Rice. Most of the vendors for large parallel systems are involved. Initial goals include: > support for managing data placement (e.g. on distributed memories) > support for data parallel programming > support tuning codes for high performance > portability between "HPF" systems > preserve working serial version of code as much as possible (so a version can run on workstations, for example). > provide directives and some minimal syntax extensions (e.g. forall) to existing Fortran standards to facilitate tapping top performance for parallel machines > track Fortran 90 terminology, semantics, syntax, etc. whenever F90 definitions are available. {e.g. don't invent new incompatible things when F90 already has something}. > give users enough so they can rewrite once - rather than incremental improvements > keep it simple ----- The Issue: - How much Fortran 90? ----- At the first working group meeting in March - there was considerable discussion about how much, if any, of Fortran 90 should be defined to be part of HPF. Customer surveys were suggested. There are parts of F90 that no one objects to ... e.g. longer names, mil-spec extensions, etc. --- everyone just assumes these are Fortran and portable. There are parts of F90 such as allocatable arrays which appear to provide important functionality for HPF. There is the F90 array syntax which provides a convenient way to express data parallelism, but isn't ABSOLUTELY required, because smart compilers can analyze the triply nested loop and spot parallism. There are things which are really unrelated, like Modules, Kind, etc. ------ The Choices: ------ There appears to be three approaches the working group can take: (1) Define a separate F90 binding and a pure F77 binding. PRO (1): This is the best way to support standards. This allows HPF to use F90 features like INTERFACE as full features of the language. This also provides a path for people who don't believe F90 will become widely available and want to stick with F77. CON (1): Users want HPF yesterday. They don't want to wait until full F90 compilers are available before they can use HPF. F77 is officially an archival standard. We should not be proposing new features. (2) Define HPF with a minimal set of extensions from F90, but basically F77. E.g. adopt memory allocation and maybe interface blocks to support redistribution of data across calls, but specifically do NOT include the array syntax. Vendors can add it if they wish, but it is not required. PRO (2): This gives maximum compatibility with workstations, etc. while still providing useful new functionality. This can be available fastest. Full array language requires compiler changes which will slow down availablity. CON (2): Users with experience using array syntax on parallel machines like it. Understanding parallel codes is hard enough. The "clean" form of array syntax is a major help. However, if it is not part of HPF standard then users interested in portability between parallel systems will not be able to use the array language unless all of the vendors support it. (3) Define HPF with the subset of useful perfomance features from F90, including array syntax. PRO (3): Users need this functionality now. Don't hold it up waiting for full F90 (where it will be part of the vendor's least mature product). Send the vendors a message that this part of F90 is important. Full F90 would be nice, but make this subset a priority. Users who are willing to trust compiler parallelism technology in exchange for workstation compatibility can choose not to use the array syntax. CON (3): Full array syntax slows down the availability. It also encourages vendors to avoid putting the proper emphasis on top quality loop optimization which is also important for HPF. ----- The opinions of your users who are potential customers of HPF are solicited. It will probably be a case of prioritizing the options (with comments). -mary zosel- ----- ----- ---- response from epfl ---- ---- Date 2.4.1992 Subject High Performance Fortran From Mark Sawley To Tom MacDonald CC Michel Jaunin, Marie-Christine Sawley, Mary Zosel Subject: High Performance Fortran ... (deleted part of message intended for Tom) In our institute we have two types of users that are closely interested in the development of HPF. The first type contains those that currently use F90 on massively-parallel machines (CM and MasPar), while the second those that are presently developing codes for current and future generation high performance computers. The requirements of the first group of users is clearly to have available as soon as possible a HPF that contains those elements of F90 that are currently being used (e.g., array syntax and intrinsics, automatic array declarations, etc.) There is not an immediate interest in other F90 features (such as, e.g., modules). This group of uses would thus strongly favour approach (3) listed in the e-mail message of Mary Zosel. The second group's requirements are slightly different. Since the thinking is perhaps more long term, it would be of interest to have available more of the F90 features, even if this means a longer compiler development time. Thus a support of the full F90 standard would be beneficial, corresponding to approach (1). At present this group is forced to write their code in F77, using a structure that allows incorporation of F90 features when, and if, they become available. As it is pointed out, there is a strong argument against incremental improvements of a compiler. However, it is hoped that the above two approaches are not mutually exclusive, and that some staging of the compiler development work will be undertaken. Having worked personally with F90 based languages, I am pleased with a number of the features (mentioned above) that distinguish it from F77. I feel that the benefits inherent in F90 - in terms of both of functionality as well as resulting code "cleanliness" - outweight the resistance to change. I would thus hope that HPF would be something more than "basically F77". I hope that the above comments give some impression of our views on HPF. Best regards, Mark From swift@maspar.com Fri Apr 10 18:06:21 1992 Received: from maspar.MasPar.COM by cs.rice.edu (AA21729); Fri, 10 Apr 92 18:06:21 CDT Received: by maspar.MasPar.COM (5.57/Ultrix3.0-C) id AA12462; Fri, 10 Apr 92 16:08:02 -0700 Received: by armada.MasPar.Com (5.57/Ultrix2.0-B) id AA25021; Fri, 10 Apr 92 16:06:37 -0700 Received: by argosy.MasPar.Com (5.57/Ultrix2.4-C) id AA05476; Fri, 10 Apr 92 16:08:13 PDT Received: by venus.MasPar.Com (5.57/Ultrix2.4-C) id AA18166; Fri, 10 Apr 92 16:04:48 -0700 Date: Fri, 10 Apr 92 16:04:48 -0700 From: swift@maspar.com (Richard Swift) Message-Id: <9204102304.AA18166@venus.MasPar.Com> To: hpff-f90@cs.rice.edu Subject: Storage/Sequence association proposal Cc: alpern@maspar.com, cdg@maspar.com, claseman@maspar.com, fbw@maspar.com, hong@maspar.com, hpff-distribute@cs.rice.edu, ian@maspar.com, ken@maspar.com, koester@maspar.com, lisa@maspar.com, pal@maspar.com, susan@maspar.com, swift@maspar.com, wendy@maspar.com Here is the proposal from the hpff-F90 subgroup on storage and sequence association as refined at the March 31 meeting at NAS. I am distributing it to both the hpff-f90@cs.rice.edu and hpff-distribute@cs.rice.edu aliases in order to get wider exposure before the April 22 meeting of the subgroup. Please comment and help us clarify any problems so that a draft can be distributed to the entire committee prior to the April meeting. I would especially appreciate someone else developing examples that could clarify any parts that anyone finds confusing or unclear. - Rick High Performance Fortran: Storage and Sequence Association Proposal 1.0 Introduction High Performance Fortran proposes to distribute arrays across multiple processors in order to help achieve parallel execution performance improvements. Fortran specifies the persistence of arrays (via the SAVE attribute), relationships between the storage for some data elements (via COMMON and EQUIVALENCE), and the order of array elements during association at procedure boundaries (via dummy array arguments). Otherwise, the location of data is not constrained by the language. The SAVE attribute is not effected by data distribution; it is an orthogonal feature. COMMON and EQUIVALENCE statments constrain the alignment of different data items based on the underlying model of storage units and storage sequences. "Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units." (Standard programming language Fortran ISO/IEC 1539:1991 (E) page 247) The model of storage association is a single linearly addressed memory, based on the traditional SISD processor. It is easy to generate examples where this model can cause gross inefficiencies for architectures where storage for arrays is distributed. Sequence association refers to the order of array elements that Fortran requires when an array expression or array element is associated with a dummy array argument that is explicit-shaped or assumed-sized. "The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, ..." (ISO/IEC 1539:1991 (E) page 174) As with storage association, sequence association is based on a linearly addressed memory, and can cause large amounts of overhead for distributed arrays. Because of the large costs involved in supporting storage and sequence association on distributed memory architectures, this proposal is based on the idea that whenever arrays are distributed, none of the properties of storage and sequence association apply to such arrays. Proposal Definitions Data distribution attributes are alignment and processor distribution of array elements in a distributed memory system. A sequential array is any array which has the properties of storage association and sequence association. A distributable array is any array which does not have the properties of storage association or sequence association. A distributed array is any distributable array which has data distribution attributes. An explicitly distributed array is any distributable array which appears in any HPF data directive that specifies its data distribution attributes in the program unit it is declared in. An implicitly distributed array is any distributable array that does not derive its data distribution attributes from explicit HPF data directives in the program unit it is declared in. A sequential COMMON block is any COMMON block which has the properties of storage association and sequence association. A distributable COMMON block is any COMMON block which does not have the properties of storage association or sequence association. End of Definitions An HPF program may contain both sequential arrays and distributed arrays. - Storage Association A distributable array may appear in COMMON statements, but not in EQUIVALENCE statements. An array is a sequential array iff the array: - appears in an EQUIVALENCE statement, or - is an assumed size array, or - is a component of a sequenced type (i.e., a structure with the SEQUENCE attribute), or - appears in a SEQUENCE directive (or via a compiler option), or - has the type CHARACTER (because of the relationship between CHARACTER arrays and strings in dummy arguments), or - appears in a sequential common block (guilt by association) An array in a sequential COMMON block may not appear in a data distribution directive. A COMMON block is a sequential COMMON block unless it can be determined to be distributable. A COMMON block is a distributable COMMON block if the COMMON block: - contains no scalars and no sequential arrays, and - contains only distributable arrays, and - contains the same sequence of arrays in each scoping unit in which the COMMON block is declared, where shape, type, and data distribution attributes of corresponding arrays of the sequence match. A COMMON block which appears as a distributable COMMON block in one program unit must not appear as a sequential COMMON block in another program unit of the same executable program. CHARACTER arrays may not be distributed. The result of an array-valued function is a distributable array, never a sequential array. Thus ENTRY statements are illegal in user written array valued functions. (Alternate ENTRY statements cause the results of functions to be storage-associated with each other.) For a COMMON block to be distributable, any data objects declared in the COMMON block must be either distributable or distributed arrays. If one or more arrays in a COMMON block are distributable but not explicitly distributed, and the only other objects in the COMMON block are distributed arrays, then such arrays are implicitly distributed with default data distribution attributes. If one or more distributable arrays appear in a distributable COMMON block, then every program unit which declares that COMMON block must declare the same number of distribute arrays in that COMMON block. Corresponding arrays in each COMMON block declaration must match in shape, type, and data distribution attributes. (Note the name of an array in COMMON is a local name, so they may be different in each COMMON declaration; however, all other attributes of the array must correspond.) - Sequence Association An assumed-size array may not be a distributed array, or associated with a distributed array. An array element designator as an actual argument may not be associated with a distributed dummy array. An array element designator of a distributable array may not be associated with a dummy array. End of Proposal Discussion By restricting the use of COMMON and EQUIVALENCE in this fashion, Fortran code satisfying these rules is still Fortran 77 compatible. Thus the restriction for users is how the language is used with HPF. Many f77 programs will work; we are only specifying which ones will not. These seem to be reasonable restrictions to impose, and automatic tools to check COMMON and generate the allowable forms are fairly straightforward. Note that these rules encourage users to utilize the same common block declaration statements in multiple program units via the INCLUDE statement. Thus the straightforward use of HPF data distribution facilities should also help to improve the maintainability and reliability of the code (which is still Fortran 77 compatible). Rules of mixing scalars and arrays in COMMON could be written up and made to work, as could complicated rules for mixing distributed and sequential arrays in the same COMMON block, but why bother? If we assume the user will rewrite applications (once only we hope) to use HPF, the simpler the rules to follow are the better. Making these rules more complicated to handle more cases is self-defeating in the long run; KISS. In essence, this proposal provides for two kinds of COMMON: one with storage association, and one without. Compilers should be able to distinguish the two without difficulty. Much of the use of COMMON blocks doesn't really care about storage association; it's an artifact of having no other way to achieve global data prior to Fortran 90. These rules result in a one-time cost of straightening out the COMMON blocks into an admittedly restricted style (which happens still to be Fortran 77 standard conforming). Eliminating the problem for distributed arrays is better than trying to propagate storage association in HPF code. All the argument passing of Fortran 77 works fine as long as actual arguments and dummy arguments are sequential arrays. If either but not both are distributed arrays, the rules for matching them up will require some kind of redistribution of data. The standard also describes storage association in the result of functions containing multiple ENTRY statements. This is a minor point. For scalar valued functions, this is fine. In HPF the result of an array-valued function should always be a distributed array, never a sequential array. Thus ENTRY statements are effectively illegal in user written array valued functions. In the absence of explicit data distribution directives, any distributable array may be implicitly distributed array by default. The distribution chosen is left to the processor. CHARACTER arrays may not be distributed. Sequence association rules are especially ugly for CHARACTER. As a simplification to vendors, it is reasonable not to require them to implement a feature which is infrequently important. Note by adding such a restriction now, it is trivial to remove it later if you wish to, such as an added feature in your product. Note that the rules of data objects in Modules are simple compared to COMMON, since Modules entail comparatively few storage association problems (Equivalence and ENTRY). Examples: The syntax is illustrative, but the ability to specify each of these attributes is needed. (The Sequence keyword is derived from the Fortran 90 attribute.) To specify an array is distributed but without specifying the distribution: subroutine one(a,b,n,c) dimension a(100), b(N), c(:), d(1000) cHPF Distributable :: a,b,c,d To specify a COMMON block is distributed without specifying the distribution: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF Distributable :: /two/ To specify explicitly that an array is NOT distributable: dimension a(100), b(N), c(:), d(1000) cHPF Sequence :: a,b,c,d To specify explicitly that a COMMON block is NOT distributable: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF Sequence :: / two / c If the directive did not appear, /two/ would be c distributable by default. In the following, e and f are explicitly distributed, but g is implicitly distributed; two is a distributed COMMON block: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF ALIGN e ... cHPF ALIGN f ... Issues: Should argument association between sequential arrays and distributed arrays be required? In general, this means some kind of redistribution across the call and back again. Pointer arrays in F90 have a lot of implementation similarity to the dynamic redistribution of allocatable arrays. The cost of referencing both constructs is complicated by not knowing at compile time where the data resides. Thus the most general case addressing must be used for distributed objects. Should pointer arrays not be supported by the base level of HPF? From zrlp09@stoy.msc.edu Tue Apr 21 08:46:04 1992 Received: from noc.msc.edu by cs.rice.edu (AA03330); Tue, 21 Apr 92 08:46:04 CDT Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA20025; Tue, 21 Apr 92 08:46:03 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA03857; Tue, 21 Apr 92 08:46:02 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA03568; Tue, 21 Apr 92 08:45:58 CDT Received: from stoy.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA17750; Tue, 21 Apr 92 08:45:55 CDT Received: from localhost by stoy.trc.amoco.com (4.1/SMI-4.1) id AA02990; Tue, 21 Apr 92 08:45:54 CDT Message-Id: <9204211345.AA02990@stoy.trc.amoco.com> To: hpff-f90@cs.rice.edu Subject: Summary of March 31 HPFF WG-1 meeting Date: Tue, 21 Apr 92 08:45:53 -0500 From: "Rex Page" Meeting of HPFF Working Group 1 Relationship of HPF to Existing Fortran Standards March 31, 1992 - NASA Ames The relationship between the rules of storage sequence and storage association in Fortran and notions of data distribution in HPF occupied the bulk of the group's attention at this meeting. Rick Swift's proposal for classifying distributable versus non-distributable arrays and COMMON blocks formed the basis of the discussion. The intent of the proposal is to restrict the application of data distribution directives to arrays that are not storage-associated with other data objects (e.g., through equivalence or arrays reshaped across procedure boundaries or differing COMMON declarations). The group clarified the proposal's definition of distributable COMMON blocks, confirmed the advisabilty of excluding CHARACTER data and scalar variables from distributable COMMON, and decided that the distribution properties of pointer types relates primarily to the issue of redistribution under program control. Consideration of the redistribution matter was deferred, waiting for recommendations from Working Group 3. Rick Swift agreed to revise his proposal to reflect the ideas developed during the meeting. There was a brief discussion of comments of potential KSR users on Fortran 90 (summarized by Bruce Knobe) and the position of X3H5 on language bindings (reported by Bruce Leasure). WG 1 arrived at no specific conclusions from this information, but arrived at a consensus that the X3H5 binding position could have gone the opposite direction, based on the evidence. Therefore, the position probably derives primarily from the inclinations of the X3H5 group. The HPFF view of language binding could easily take a different turn. The remaining time during the meeting was devoted mostly to discussing the HPF base language: Fortran 77? Fortran 90? Restricted Fortran 90? Two bindings? Much of the discussion focussed on the issue of which Fortran 90 features the HPF specification should or would include. The group agreed that the HPF defining document should include a section listing the facilities of Fortran 90 touched by HPF and a cross listing of the HPF features relating to those facilities. It would be premature to say, at this point, which Fortran 90 facilities would be involved. Therefore, rather than making an explicit recommendation on this issue now, the group is inclined to encourage the HPF Forum to include in their proposals those Fortran 90 elements that are relevant to the HPF features being defined. The Forum would then produce a cross listing of HPF/Fortran 90 features at the end of the process. WG 1 agreed to meet in Dallas on the afternoon of April 22 to put the final touches on its proposal regarding distributable variables and its recommendation on HPF/Fortran bindings. Report submitted by Rex Page, ad hoc secretary, HPFF WG 1 From halstead@crl.dec.com Tue Apr 21 09:53:01 1992 Received: from crl.dec.com by cs.rice.edu (AA04896); Tue, 21 Apr 92 09:53:01 CDT Received: by crl.dec.com; id AA24700; Tue, 21 Apr 92 10:52:47 -0400 Received: by easynet.crl.dec.com; id AA07744; Tue, 21 Apr 92 10:51:02 -0400 Message-Id: <9204211452.AA18332@seine.crl.dec.com> To: swift@maspar.com (Richard Swift) Cc: halstead@crl.dec.com, hpff-f90@cs.rice.edu, hpff-distribute@cs.rice.edu Subject: Re: Storage/Sequence association proposal In-Reply-To: Your message of "Fri, 10 Apr 92 16:04:48 PDT." <9204102304.AA18166@venus.MasPar.Com> Date: Tue, 21 Apr 92 10:52:45 -0400 From: halstead@crl.dec.com X-Mts: smtp > Here is the proposal from the hpff-F90 subgroup on storage and > sequence association as refined at the March 31 meeting at NAS. ... Basically, I think the proposal is very clear and well thought out. I do have a couple of comments on a few detailed points, however, that I thought I ought to pass along: > If one or more arrays in a COMMON block are distributable but > not explicitly distributed, and the only other objects in the > COMMON block are distributed arrays, then such arrays are > implicitly distributed with default data distribution attributes. As I commented previously to hpff-distribute in another context, I feel that the HPF proposal shouldn't imply that there are any kind of implementation-wide "default data distribution attributes." An implementation might well have such a set of defaults, but it should also be allowed to use different "defaults" in different cases, however it might be able to determine would be best. It should even, in my opinion, be allowed to use different mappings at different times for the same object, if no explicit distribution is specified, whenever that seems like the way to generate the most efficient program. In other words, any time that no explicit distribution attributes are specified, the compiler has free license to optimize the program in any way it wants, as long as the semantics of the program are preserved. > Issues: > > Should argument association between sequential arrays and > distributed arrays be required? In general, this means some > kind of redistribution across the call and back again. I would say yes, and since all proposals being considered by hpff-distribute have the potential for argument redistribution across calls, I don't think it would be revolutionary to allow such redistribution here. And I predict that not allowing such redistribution would create a significant nuisance for programs that use sequential arrays. > Pointer arrays in F90 have a lot of implementation similarity > to the dynamic redistribution of allocatable arrays. > The cost of referencing both constructs is complicated by > not knowing at compile time where the data resides. Thus the > most general case addressing must be used for distributed objects. > Should pointer arrays not be supported by the base level of HPF? In Digital's proposal to the January HPFF meeting, we proposed that it would be illegal to specify any alignment or distribution for objects with the POINTER or TARGET attributes. This approach avoided a bunch of questions about whether the distribution attributes of pointers would have to match those of the pointer's targets, etc., and it wasn't clear to us whether using pointers to point to explicitly distributed objects was going to be a very important capability anyhow. The proposal would allow a compiler that has a simple default mapping for objects without explicit distribution attributes to just use those defaults for pointers and their targets, while leaving the door open for cleverer compilers to do cleverer things some day. -Bert From zosel@phoenix.ocf.llnl.gov Mon Apr 27 19:34:11 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA10250); Mon, 27 Apr 92 19:34:11 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA07304; Mon, 27 Apr 92 17:34:17 -0700 Date: Mon, 27 Apr 92 17:34:17 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9204280034.AA07304@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: meeting time Subgroup 1 We were supposed to check our schedules for the week of May 11 for a subgroup meeting - with a tentative date of May 12. (Any day that week except thursday the 14th is ok with me.) Can you send me your preferences directly to zosel@llnl.gov and I'll sort thru to pick the date. -mary- From zosel@phoenix.ocf.llnl.gov Wed Apr 29 11:26:31 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA02040); Wed, 29 Apr 92 11:26:31 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA15659; Wed, 29 Apr 92 09:26:38 -0700 Date: Wed, 29 Apr 92 09:26:38 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9204291626.AA15659@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: group 1 meeting Group 1 There has been a suggestion put forward that we make a serios try to do our work via email for the next meeting. There is no ideal match for everyone for a meeting the week of May 11 (perhaps Monday the 11th) was the best fit - but not ideal.) I propose we work with email - and if that is failing - we will convene as many people as possible sometime during the week of May 26 to guarentee that we are prepared for the next meeting. David Loveman will be working on a proposal for the array language - to be presented at the June meeting. Everyone is supposed to be working on user feedback about how liberal or conservative we should be about common-block storage assosiation rules. Rick Swift would like to continue developing the formal proposal for storage/sequence association - stated in an incremental fashion so the full committee can rule on Andy and Ken's more flexible interpretations. It would be good to have someone research in more detail and prepare a written statement about what the difficulties with CHARACTER are. I believe this would be helpful to the full committee in deciding whether or not to exclude the data type from the subset / directives. Is there a volunteer? Barry's pointer paper is also up for discussion - we referred it to the distribution subgroup - but should make sure it doesn't get lost. There was also the question of getting info from X3J3 about why the forall and nested where, etc. were dropped from F90. These are actually issues for group 4, but we might help. ---- Comments please on the proposal to work via email. Also additions to our work list? And any volunteers? Discussion on other f90 related issues also always welcome. -mary- From schreibr@riacs.edu Wed Apr 29 13:06:50 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA04869); Wed, 29 Apr 92 13:06:50 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA10686; Wed, 29 Apr 92 11:06:46 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA04675; Wed, 29 Apr 92 11:06:06 PDT Message-Id: <9204291806.AA04675@thor.riacs.edu> Date: Wed, 29 Apr 92 11:06:06 PDT From: Rob Schreiber To: hpff-f90@cs.rice.edu, zosel@phoenix.ocf.llnl.gov Subject: Re: group 1 meeting Email is a good idea. Barry's paper made the assumption that a pointer can or should be distributed and that redistribution of the pointer redistributes the data it points to. Also, he proposed distributing an unassociated pointer and then allocating storage that it points to, with inheritance of the distribution from the pointer to the newly allocated storage. I dont like the idea of distributing and array through a pointer to it. Also, what happens if the pointer is pointing to a subarray? Proposal 1: Pointers not allowed in distribution or alignment. Target are allowed. If a pointer points at a target or subarray of a target, it gets the distribution that the target has. IF THE TARGET's distribution changes, then so does the pointer's. (This requires a fancy implementation of pointers to redistributable targets.) Note that this does not allow explicit distribution of the storage allocated by ALLOCATE using a pointer variable. End of proposal. If that's too restrictive: Proposal 2: Just like Proposal 1, except that Pointers are allowed in alignment and distribution directives, only if they point at allocated storage, never if they are pointing to a target array. End of proposal. Is something like this workable? From halstead@crl.dec.com Thu Apr 30 10:32:21 1992 Received: from crl.dec.com by cs.rice.edu (AA25870); Thu, 30 Apr 92 10:32:21 CDT Received: by crl.dec.com; id AA19544; Thu, 30 Apr 92 09:59:36 -0400 Received: by easynet.crl.dec.com; id AA12654; Thu, 30 Apr 92 10:44:25 -0400 Message-Id: <9204301446.AA16427@seine.crl.dec.com> To: Rob Schreiber Cc: halstead@crl.dec.com, hpff-f90@cs.rice.edu Subject: mapping of pointers In-Reply-To: Your message of "Wed, 29 Apr 92 11:06:06 PDT." <9204291806.AA04675@thor.riacs.edu> Date: Thu, 30 Apr 92 10:46:11 -0400 From: halstead@crl.dec.com X-Mts: smtp How important will the use of pointers to explicitly mapped arrays be to High Performance Fortran users? I can think of a number of reasons why it might not be so important: 1. Pointers are a new feature in Fortran 90 that was not present in FORTRAN 77, so FORTRAN 77 users are probably not accustomed to using (at least) Fortran 90 pointers. 2. Fortran 90 has other features, such as allocatable arrays, array sections, and explicit array reshaping operators, which take over many of the uses of the FORTRAN 77 pointer extensions, such as Cray pointers, without requiring the use of Fortran 90 pointers. 3. Probably the most useful application of pointers that does not fall into any of the categories listed above is the use of pointers to derived-type objects (structures), to make linked data structures of various kinds. But it is already impossible to specify a mapping for structures because they aren't arrays. When we put together the Digital proposal that was presented at the January HPFF meeting, we stipulated that no explicit mapping could be specified either for pointers or for objects declared with the TARGET attribute. I think this is more draconian than either of your models 1 or 2. We did this because of some of the implementation concerns that you raise, and because we felt we were lacking a strong model of what the real needs of users would be in specifying mappings for pointers or their targets. I still believe in our model and would like to put it forward for serious consideration. It will be much easier to add the ability to specify mappings for pointers and targets to a later version of HPF than it will be to take away or revise a mapping capability that we define now and later become unhappy with. To change my mind about this, I would want to see a combination of the following two: a. Some examples from real application practice in which an inability to specify pointers to explicitly mapped arrays will create a significant problem. b. A theory about how a proposed solution to the problems in (a) can be implemented without imposing considerable costs on "simple" uses of pointers. Frankly, I suspect that pointers to explicitly mapped arrays should go fairly far down on the priority list of things that HPF needs to support in order to be useful, so I think we should beware of falling into a rathole about it. But that's mostly because I haven't seen any examples of the type described in (a) above. I'd be happy to be educated on this point by some feedback from real users. -Bert Halstead From schreibr@riacs.edu Thu Apr 30 10:42:58 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA26087); Thu, 30 Apr 92 10:42:58 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA16537; Thu, 30 Apr 92 08:42:55 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA04852; Thu, 30 Apr 92 08:42:13 PDT Message-Id: <9204301542.AA04852@thor.riacs.edu> Date: Thu, 30 Apr 92 08:42:13 PDT From: Rob Schreiber To: halstead@crl.dec.com Subject: Re: mapping of pointers Cc: hpff-f90@cs.rice.edu Thanks for the comments on pointers to mapped arrays; I dont know of any example of the kind you ask for (usefulness of pointer to mapped array). Rob From meltzer@tamarack.cray.com Thu Apr 30 17:44:23 1992 Received: from timbuk.cray.com by cs.rice.edu (AA07003); Thu, 30 Apr 92 17:44:23 CDT Received: from willow14.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA22893; Thu, 30 Apr 92 17:44:21 CDT Received: by willow14.cray.com id AA03529; 4.1/CRI-5.6; Thu, 30 Apr 92 17:44:20 CDT Date: Thu, 30 Apr 92 17:44:20 CDT From: meltzer@tamarack.cray.com (Andy Meltzer) Message-Id: <9204302244.AA03529@willow14.cray.com> To: hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu Subject: COMMON with sequence and storage assoc As promised, what follows is a suggestion for an extension to the hpff-f90 group's proposal. This extension deals exclusively with distributing COMMON blocks while maintaining sequence and storage association. I'm working on getting some example codes which will find this extension particularly useful. I will probably not be able to post them for some weeks yet, however. ############################################# COMMON blocks with Sequence and Storage Association Suggestion for extension to group 1 (hpff-F90) Proposal Currently in the group 1 proposal, COMMON blocks are not allowed to both maintain sequence and storage association and be explicitely distributed by the user. This extension allows the user to specify the distribution of a COMMON block with sequence and storage association. DEFINITIONS: As is currently proposed: "A sequential COMMON block is any COMMON block which has the properties of storage association and sequence association." "A distributable COMMON block is any COMMON block which does not have the properties of storage association or sequence association." These definitions combine two concepts into one (they are used as antonyms in the proposal.) In a program there may be the assertion by the user that sequence and storage association must be maintained, this is a correctness issue. The user may also wish to guide the compiler as to his/her choice of how to distribute the COMMON block; this is a performance issue. I will use the directive "MSASA" to indicate that the user wants to Maintain Sequence And Storage Association, and "NO MSASA" as its antonym. A common block may be mapped across the processors using the same syntax as an array which is mapped across the processors (more on this later.) RATIONALE: There are many reasons why a user may desire to map a COMMON block across the memories of a machine and still maintain sequence and storage association. I will enumerate a few of them here. Note that in all cases where I refer to COMMON blocks I am speaking of COMMON blocks which require sequence and storage association (MSASA COMMON). 1. Porting old codes. Many user's have codes which they want to port to MPPs. These codes currently make extensive use of COMMON blocks for which sequence and storage association are heavily relied upon. While it is not my opinion that a user will get optimal performance simply be distributing these COMMON blocks, allowing them to do so will give them a faster path to parallelism and on many machines allow them to process their distributed data in parallel. Although their processing will be on predominantly non-local references, it will, nontheless, be in parallel. On many machines, being able to do 1000 things at a time, even with the overhead of non-local data accesses will be considerably faster than sequentially processing everything. For those COMMON blocks where this is the case the user should be allowed to specify the appropriate mapping. Where an implementation does not feel that a particular layout is appropriate, it may be ignored. 2. Replicated Storage. On shared memory machines some COMMON blocks may be more ideally suited to being replicated across processors. While occasionally a compiler may be able to determine this, without interprocedural analysis it is a difficult optimization. If the data in COMMON block is rarely updated, the performance of an application may benefit greatly by having local copies to refer to. The user will generally be able to determine this and should be able to tell the compiler. 3. Memory availability. We have a number of customers who are concerned that their codes will not fit within any single node's memory. This need of the users must be met. 4. HPF user flexibility. We as language designers cannot know all of the ways which our users will conceive of using HPF, we should therefore not try to force restrictions upon them. As far as I have seen, sophisticated users of languages for MPPs have spent a large amount of effort trying to get around weaknesses and restrictions in languages. To purposefully put one of these in their way seem counter-productive. 5. Ease of understanding. A language is simpler to understand if each directive embodies only one concept. Whether or not we decide that a COMMON block may have its distribution specified by the user, differentiating between the concepts of maintaining sequence and storage association, and the distribution of a COMMON block makes the directives clearer. It also allows a pathway for allowing the feature in the future. The main arguments against allowing users to specify a distribution for a COMMON block with sequence and storage association is that it is of questionable use and that it will inevitable lead to poor performance. Its usefulness should be determined by the user community. It is not hard to implement. It can simply be ignored by those vendors who feel that users will not take advantage of it. It is a porting aid. While there are many cases where mapping COMMON blocks across processors is a bad idea, it will not always reduce performance. As point (2) above states, replication may be a good idea. As point (1) states, there are codes for which it will provide speedup. SYNTAX: - The syntax of distributing MSASA COMMON is identical to the syntax of distributing other COMMON blocks where applicable. Restrictions are listed in the semantics section. - The syntax for ALIGNing an MSASA COMMON block is identical to the syntax for ALIGNing an ordinary COMMON. - An additional keyword is added "MSASA" and its inverse "NOMSASA" to indicate that sequence and storage association is required. NOMSASA is the default for COMMON blocks which are explicitely distributed or replicated. MSASA is the default for other COMMON blocks. msasa-directive is MSASA [::] msasa-list msasa-item is /common-block-name/ example: COMMON /XXX/ A(40), B(50,60), C COMMON /YYY/ D(40), E(50,60) CHPF$ MSASA:: /XXX/, /YYY/ - Since one cannot specify a template for the distribution, an additional keyword REPLICATE is added. It is used in place of the keyword DISTRIBUTE. With REPLICATE no blocking attribute can be specified. replicate-directive is REPLICATE repl-stuff repl_stuff is single-repl-stuff or fancy-repl-stuff fancy-repl-stuff is fancy-attr-stuff :: msasa-list fancy-attr-stuff is [ONTO repl-target] single-repl-stuff is msasa-item [ONTO repl-target] repl-target is processors-name example: CHPF$ PROCESSORS P(256) COMMON /XXX/ A(40), B(50,60), C COMMON /YYY/ D(40), E(50,60) COMMON /ZZZ/ F(10), G(50) CHPF$ MSASA:: /XXX/, /YYY/ CHPF$ REPLICATE ONTO P :: /XXX/, /YYY/ CHPF$ REPLICATE /ZZZ/ ONTO P SEMANTICS: There are not many rules necessary for MSASA COMMON blocks. They are intended to behave much like ordinary COMMON blocks. The semantic restrictions are only in place to prevent the programmer from trying to ask for nonsense. While this approach may lead to some poorly performing programs (in the case, for example, of a COMPLEX number crossing PE boundaries,) it leaves the user with a clean simple set of guidelines. - An MSASA COMMON block cannot be ALIGNed to any template other than its own (implicitely) or the template of an MSASA COMMON block of equal or larger size. While aligning MSASA COMMON with these restrictions appears to be meaningless, it is not. There may be implementations which choose not to automatically map all objects to the hardware in an identical fashion. example: CHPF$ PROCESSORS P(256) COMMON /XXX/ A(40), B(50,60), C COMMON /YYY/ D(40), E(50,60) CHPF$ MSASA:: /XXX/, /YYY/ CHPF$ DISTRIBUTE /XXX/ ONTO P CHPF$ ALIGN /YYY/ WITH /XXX/ C The inverse alignment would be illegal - A BLANK COMMON cannot be specified as MSASA. HPF may decide that its default is MSASA, however the decision is outside the scope of this proposal. - No data item can be aligned with a data item in an MSASA COMMON block nor can it be aligned with the MSASA COMMON block. - No data item from an MSASA COMMON may be separately ALIGNED or DISTRIBUTED. - An MSASA COMMON block may not be redistributed or realigned. - Correctness of implementation is all that must be maintained. This directive (as is true of many others) may be considered a suggestion by an HPF conforming implementation. open issue: It makes sense to allow the user to specify SMOOTH, CYCLIC, or BLOCK. Does it make sense to allow the user to specify BLOCK sizes since these may vary from machine to machine? In my opinion (at this moment) this should be allowed, but I am not yet confident of this. Andy Meltzer From shapiro@think.com Tue May 5 14:26:25 1992 Received: from mail.think.com (Mail1.Think.COM) by cs.rice.edu (AA02431); Tue, 5 May 92 14:26:25 CDT Return-Path: Received: from Aeolus.Think.COM by mail.think.com; Tue, 5 May 92 15:26:20 -0400 From: Richard Shapiro Received: by aeolus.think.com (4.1/Think-1.0C) id AA10510; Tue, 5 May 92 15:26:18 EDT Date: Tue, 5 May 92 15:26:18 EDT Message-Id: <9205051926.AA10510@aeolus.think.com> To: halstead@crl.dec.com Cc: schreibr@riacs.edu, halstead@crl.dec.com, hpff-f90@cs.rice.edu Subject: mapping of pointers How important will the use of pointers to explicitly mapped arrays be to High Performance Fortran users? I can think of a number of reasons why it might not be so important: I expect that pointers to explicitly mapped arrays will be quite important. Suppose I need a number of global, dynamically allocated objects. What is the appropriate mechanism for dealing with these arrays? The methoid that comes to my mind immediately is a common block which contains a whole bunch of pointers. I then go allocate the arrays and assign them to the pointers. Is there a better way? Is this perhaps what modules are supposed to do? 1. Pointers are a new feature in Fortran 90 that was not present in FORTRAN 77, so FORTRAN 77 users are probably not accustomed to using (at least) Fortran 90 pointers. This argument is specious. A LOT of Fortran 90 features are not in FORTRAN 77. 2. Fortran 90 has other features, such as allocatable arrays, array sections, and explicit array reshaping operators, which take over many of the uses of the FORTRAN 77 pointer extensions, such as Cray pointers, without requiring the use of Fortran 90 pointers. Except for the global, allocatable data. Frankly, I suspect that pointers to explicitly mapped arrays should go fairly far down on the priority list of things that HPF needs to support in order to be useful, so I think we should beware of falling into a rathole about it. But that's mostly because I haven't seen any examples of the type described in (a) above. I'd be happy to be educated on this point by some feedback from real users. -Bert Halstead I hope this helps, but perhaps it is I who need the education vis a vis modules. Richard Shapiro, United Technologies Corporation (shapiro@think.com) From halstead@crl.dec.com Tue May 5 14:50:26 1992 Received: from crl.dec.com by cs.rice.edu (AA03838); Tue, 5 May 92 14:50:26 CDT Received: by crl.dec.com; id AA02654; Tue, 5 May 92 15:50:24 -0400 Received: by easynet.crl.dec.com; id AA10420; Tue, 5 May 92 15:48:34 -0400 Message-Id: <9205051950.AA10965@seine.crl.dec.com> To: Richard Shapiro Cc: halstead@crl.dec.com, hpff-f90@cs.rice.edu Subject: Re: mapping of pointers In-Reply-To: Your message of "Tue, 05 May 92 15:26:18 EDT." <9205051926.AA10510@aeolus.think.com> Date: Tue, 05 May 92 15:50:21 -0400 From: halstead@crl.dec.com X-Mts: smtp > I expect that pointers to explicitly mapped arrays will be quite important. > Suppose I need a number of global, dynamically allocated objects. What is > the appropriate mechanism for dealing with these arrays? The methoid that > comes to my mind immediately is a common block which contains a whole bunch > of pointers. I then go allocate the arrays and assign them to the pointers. Well, that is a good point. I hadn't thought about the fact that common blocks can't have allocatable arrays in them, even though they can have pointers to arrays. Modules can in fact be used for this purpose -- see the example in Section 11.3.3.4 of the Fortran 90 standard. But I suppose this is only relevant if HPF actually includes modules. > 1. Pointers are a new feature in Fortran 90 that was not present in > FORTRAN 77, so FORTRAN 77 users are probably not accustomed to using > (at least) Fortran 90 pointers. > > This argument is specious. A LOT of Fortran 90 features are not in FORTRAN 77. I'm sorry you didn't like my argument. I only meant to say that upward compatibility from FORTRAN 77 would not be one of the reasons to support lots of ways to use pointers -- I didn't mean to imply that there might not be other reasons; in fact, I sent the message to find out what other reasons there might be. Thanks for your comments! -Bert From shapiro@think.com Tue May 5 15:02:54 1992 Received: from mail.think.com (Mail1.Think.COM) by cs.rice.edu (AA04663); Tue, 5 May 92 15:02:54 CDT Return-Path: Received: from Aeolus.Think.COM by mail.think.com; Tue, 5 May 92 16:02:52 -0400 From: Richard Shapiro Received: by aeolus.think.com (4.1/Think-1.0C) id AA10522; Tue, 5 May 92 16:02:51 EDT Date: Tue, 5 May 92 16:02:51 EDT Message-Id: <9205052002.AA10522@aeolus.think.com> To: meltzer@tamarack.cray.com Cc: hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu In-Reply-To: Andy Meltzer's message of Thu, 30 Apr 92 17:44:20 CDT <9204302244.AA03529@willow14.cray.com> Subject: Some philosophy (relating to HPFF) I've been doing some thinking (well, philosophizing really) about the larger issues in the discussions in sequence and storage order debate (as well as the F90 debate). I've come to the conclusion that HPF should specify only a few things that *everyone* should have (for example, the minimal subset of Fortran 90 + some form of FORALL), and the rest should be of the flavor "If you have functionality X, do it this way" I think this will make it a lot easier to agree on some things (for example, Andy's suggestions about COMMON blocks and storage association), while at the same time maintaining a common syntax and semantics for more architecture and vendor specific features. I propose that we try to make the directives have as much functionality as we want (including, perhaps, some fairly specific functionality), while trying to preserve a relatively easy-to-understand model. Them we simply say to any implementor that they can implement as much or as little of the functionality as they want. The gist of this comment is that I don't think we should spend a lot of time debating the merits of allowing users to distribute COMMON blocks or pointer targets. Rather, we should specify what it means to do so and let the vendors decide whether they want to implement a feature. On Andy's proposal itself: I don't like the name MSASA. It's useful for discussion, but without context it's not obvious what it means. I'd prefer something like "LINEARMODEL" or "STORAGE_ASSOCIATE". My feeling is that no restrictions should be placed on distribution templates, so I should be able to align my entire COMMON block with a template of the appropriate size. What the "storage unit" means should be left up to the vendor. For example, on a Cray, the storage unit might be 8 bytes, while on a CM-2, it might be 4 bytes. Users already have to deal with this kind of issue in F77 codes, and this doesn't seem any worse than what we already have. From serafini@ra-iris9.arc.nasa.gov Tue May 5 15:30:15 1992 Received: from ames.arc.nasa.gov by cs.rice.edu (AA07202); Tue, 5 May 92 15:30:15 CDT Received: from ra-iris9.arc.nasa.gov by ames.arc.nasa.gov (5.65c/1.21) with SMTP id AA25578 for <@ames.arc.nasa.gov:hpff-f90@cs.rice.edu> on Tue, 5 May 1992 13:30:08 -0700 Received: by ra-iris9.arc.nasa.gov (5.52/901025.SGI.UNSUPPORTED.PROTOTYPE) (for @ames.arc.nasa.gov:schreibr@riacs.edu) id AA01658; Tue, 5 May 92 13:29:56 PDT Date: Tue, 5 May 92 13:29:56 PDT Message-Id: <9205052029.AA01658@ra-iris9.arc.nasa.gov> From: David B. Serafini Sender: serafini@ra-iris9.arc.nasa.gov To: shapiro@think.com Cc: halstead@crl.dec.com, schreibr@riacs.edu, halstead@crl.dec.com, hpff-f90@cs.rice.edu In-Reply-To: Richard Shapiro's message of Tue, 5 May 92 15:26:18 EDT <9205051926.AA10510@aeolus.think.com> Subject: mapping of pointers [Bert Halstead (halstead@crl.dec.com) writes...] How important will the use of pointers to explicitly mapped arrays be to High Performance Fortran users? I can think of a number of reasons why it might not be so important: [Rich Shapiro (shapiro@think.com) replies...] I expect that pointers to explicitly mapped arrays will be quite important. Suppose I need a number of global, dynamically allocated objects. What is the appropriate mechanism for dealing with these arrays? The methoid that comes to my mind immediately is a common block which contains a whole bunch of pointers. I then go allocate the arrays and assign them to the pointers. Is there a better way? Is this perhaps what modules are supposed to do? As some of us have already discovered with CM Fortran, this seems to be the most reasonable way to implement multi-block CFD algorithms w.r.t. memory efficiency. In CMF a compiler-dependent array descriptor is used instead of the pointer, and a dynamic array of these descriptors is built so the implementation can loop through the solver algorithm for each block, when the number and size of the blocks is unknown at compile time. The result is a hierarchical data structure that is completely allocatable at run-time. -David From schreibr@riacs.edu Tue May 5 16:04:56 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA09925); Tue, 5 May 92 16:04:56 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA05209; Tue, 5 May 92 14:04:47 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA11119; Tue, 5 May 92 14:04:03 PDT Message-Id: <9205052104.AA11119@thor.riacs.edu> Date: Tue, 5 May 92 14:04:03 PDT From: Rob Schreiber To: serafini@ra-iris.arc.nasa.gov, shapiro@think.com Subject: Re: mapping of pointers Cc: halstead@crl.dec.com, hpff-f90@cs.rice.edu, schreibr@riacs.edu These are good arguments; the use that David Serafini has discussed cannot be duplicated by a collection of allocatable arrays in a module. Still, distribution and pointer has the potential to be what Bert called a "rathole". I earlier proposed that realignment and redistribution of pointer arrays (not arrays of pointers) should be allowed, but only when the pointer points to dynamic storage. There is no way to realign or redistribute such storage except through the pointer. The pointer cannot be pointed at a subarray of the array. The pointer would have to be declared redistributable. It should not be possible to use a pointer in an align or distribute (static) directive, only to realign or redistribute following allocation. I would continue to bar explicit alignment and distribution of target arrays. Is this too complicated? From mwolfe@cse.ogi.edu Tue May 5 17:59:37 1992 Received: from cse.ogi.edu by cs.rice.edu (AA17232); Tue, 5 May 92 17:59:37 CDT Received: by cse.ogi.edu (5.61+eap+OGI_1.1.named/IDA-1.2.8+OGI_1.12) id AA15129; Tue, 5 May 92 15:59:30 -0700 Date: Tue, 5 May 92 15:59:30 -0700 From: Michael Wolfe Message-Id: <9205052259.AA15129@cse.ogi.edu> To: halstead@crl.dec.com, shapiro@think.com Subject: Re: mapping of pointers Cc: hpff-f90@cs.rice.edu, schreibr@riacs.edu Sorry to interject, but: > I expect that pointers to explicitly mapped arrays will be quite important. > Suppose I need a number of global, dynamically allocated objects. What is > the appropriate mechanism for dealing with these arrays? The methoid that > comes to my mind immediately is a common block which contains a whole bunch > of pointers. I then go allocate the arrays and assign them to the pointers. > Is there a better way? Is this perhaps what modules are supposed to do? The most appropriate way, given your brief description, is not pointers, but "allocatable" arrays. These are dynamically allocatable arrays, much like pointers, except they can only point to dynamically allocated data; pointers, on the other hand, can point to subarrays of other arrays, either dynamic or not. Dynamic allocation will be extremely important, but the F90 pointer is not the only way to do it. From schreibr@riacs.edu Wed May 6 10:46:46 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA01979); Wed, 6 May 92 10:46:46 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA19998; Wed, 6 May 92 08:46:36 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA00467; Wed, 6 May 92 08:45:51 PDT Message-Id: <9205061545.AA00467@thor.riacs.edu> Date: Wed, 6 May 92 08:45:51 PDT From: Rob Schreiber To: mwolfe@cse.ogi.edu Subject: Re: mapping of pointers Cc: halstead@crl.dec.com, hpff-f90@cs.rice.edu, shapiro@think.com Dear Mike, I think you missed something: The allocated data in the application at hand is global. Allocatable arrays may not be placed in common blocks, pointers may. One may use modules, true. (Modules may or may ot be in the "minimal subset".) But a second aspect of the application of David Serafini is the use of a dynamically determined NUMBER of dynamic arrays. To do this, he allocates an array of pointers, the size of which is determined at runtime. Then he allocates storage for each of the allocated pointers. If every one of his allocated arrays had to have its own name, this would be difficult to do. Rob From joelw@mozart.convex.com Wed May 6 13:50:30 1992 Received: from convex.convex.com by cs.rice.edu (AA10524); Wed, 6 May 92 13:50:30 CDT Received: from mozart.convex.com by convex.convex.com (5.64/1.35) id AA14845; Wed, 6 May 92 13:50:11 -0500 Received: by mozart.convex.com (5.64/1.28) id AA27284; Wed, 6 May 92 13:50:09 -0500 From: joelw@mozart.convex.com (Joel Williamson) Message-Id: <9205061850.AA27284@mozart.convex.com> Subject: Re: mapping of pointers To: halstead@crl.dec.com Date: Wed, 6 May 92 13:50:08 CDT Cc: schreibr@riacs.edu, hpff-f90@cs.rice.edu, hpff-distribute@cs.rice.edu In-Reply-To: <9205061824.AA17751@seine.crl.dec.com>; from "halstead@crl.dec.com" at May 6, 92 2:24 pm X-Mailer: ELM [version 2.3 PL11] halstead@crl.dec.com writes: > > DO K = 1, 4 > CHPF$ REALIGN A(K)%B(I,J) WITH D((2**(4-K))*I,(2**(4-K))*J) > END DO > > which seems to capture what we want. This won't work because any > variable names appearing on the "left-hand side" of an ALIGN/REALIGN > directive are deemed to introduce a new scope for that name, valid for > the rest of the directive. So the K in the directive actually has > nothing to do with the loop index K. This too would have to be changed > in order to solve our problem. > What the heck, Fortran has already solved this one: CHPF$ (REALIGN A(K)%B(I,J) WITH D((2**(4-K))*I,(2**(4-K))*J), K = 1, 4) Joel From halstead@crl.dec.com Wed May 6 13:24:29 1992 Received: from crl.dec.com by cs.rice.edu (AA09595); Wed, 6 May 92 13:24:29 CDT Received: by crl.dec.com; id AA16146; Wed, 6 May 92 14:24:19 -0400 Received: by easynet.crl.dec.com; id AA20252; Wed, 6 May 92 14:22:28 -0400 Message-Id: <9205061824.AA17751@seine.crl.dec.com> To: Rob Schreiber Cc: halstead@crl.dec.com, hpff-f90@cs.rice.edu, hpff-distribute@cs.rice.edu Subject: Re: mapping of pointers In-Reply-To: Your message of "Wed, 06 May 92 08:45:51 PDT." <9205061545.AA00467@thor.riacs.edu> Date: Wed, 06 May 92 14:24:16 -0400 From: halstead@crl.dec.com X-Mts: smtp > Date: Wed, 6 May 92 08:45:51 PDT > From: Rob Schreiber > To: mwolfe@cse.ogi.edu > Subject: Re: mapping of pointers > Cc: halstead, hpff-f90@cs.rice.edu, shapiro@think.com > > Dear Mike, > > I think you missed something: > > The allocated data in the application at hand is global. Allocatable > arrays may not be placed in common blocks, pointers may. > > One may use modules, true. > (Modules may or may ot be in the "minimal subset".) > But a second aspect of the application of > David Serafini is the use of a dynamically determined NUMBER > of dynamic arrays. To do this, he allocates an array of pointers, > the size of which is determined at runtime. Then he allocates storage > for each of the allocated pointers. If every one of his allocated > arrays had to have its own name, this would be difficult to do. This last point is certainly true. But I wonder a bit about how you actually construct this object, and how it would relate to the ALIGN/REALIGN syntax that HPF is likely to have: 1. Just creating an array of pointers is moderately challenging. Section 6.2.2 of the Fortran 90 standard states that "An array element ... never has the POINTER attribute." So you can't just declare an array of pointers the way you might in a C program. Presumably you have to define a one-element derived type that contains the pointer, and make an array of those objects. 2. Now, how do you specify a [re]mapping for the targets of the pointers (as opposed to the "top-level" array of derived-type entities)? In the January HPF proposal from Digital, we tried to be clear that you could only specify alignments for top-level arrays, so in particular any derived-type entity, no matter whether it included an array, could only be aligned with a single decomposition point. Otherwise you may end up having to deal with alignment directives such as CHPF$ ALIGN A(I,J)%B(K,L) WITH D(K,J,L) or if you try to rule such things out, then you have to devise a set of rules that excludes the cases you don't want to think about but includes the things that people want to do. I haven't seen any HPF proposals floating through the Internet that would allow this, though I suppose some people who would actually like to be able to do this may not have thought explicitly about this issue before now. 3. But in order to handle David Serafini's wishes, we may even have to go beyond this capability, to allow a set of directives something like, CHPF$ REALIGN A(1)%B(I,J) WITH D(8*I,8*J) CHPF$ REALIGN A(2)%B(I,J) WITH D(4*I,4*J) CHPF$ REALIGN A(3)%B(I,J) WITH D(2*I,2*J) CHPF$ REALIGN A(4)%B(I,J) WITH D(I,J) or the equivalent executed inside of a loop. This differs from previous proposals for the ALIGN directive in that the same "top-level" name A (or "A%B" if you prefer) is mentioned several times in REALIGN directives that don't cancel each other because parameters appear in the "left-hand side" of the REALIGN directive that make each directive apply to a different _part_ of the object! This is a major step beyond what I believe to be the current proposals for mapping directives, but if we don't take this step, David Serafini's examples won't work as an argument for being able to align pointers. Now that I think of it, there's another problem with the scenario of writing a loop (which I assume is what one would like to do) to handle the above realignments. Suppose we write the loop DO K = 1, 4 CHPF$ REALIGN A(K)%B(I,J) WITH D((2**(4-K))*I,(2**(4-K))*J) END DO which seems to capture what we want. This won't work because any variable names appearing on the "left-hand side" of an ALIGN/REALIGN directive are deemed to introduce a new scope for that name, valid for the rest of the directive. So the K in the directive actually has nothing to do with the loop index K. This too would have to be changed in order to solve our problem. This message has probably gotten too long already. The main point is, while the idea of using REALIGN directives in this way on arrays of pointers is clever, it goes quite a bit beyond what is currently being proposed, in many more ways than just by involving dynamic realignment of pointers. If we want to support this idiom, a lot of things will need to be reconsidered. -Bert From martin@ocfmail.ocf.llnl.gov Thu May 7 17:53:45 1992 Received: from ocfmail.ocf.llnl.gov ([134.9.48.4]) by cs.rice.edu (AA24886); Thu, 7 May 92 17:53:45 CDT Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA04117; Thu, 7 May 92 15:55:48 PDT Date: Thu, 7 May 92 15:55:48 PDT From: martin@ocfmail.ocf.llnl.gov (Jeanne Martin) Message-Id: <9205072255.AA04117@ocfmail.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: Mapping of Pointers Mary Zosel asked me to review some of your recent messages on the mapping of pointers. I am a long-time member of X3J3, Convenor of WG5, and the author of the pointer proposal that was eventually adopted. (That doesn't mean I like everything about it; in a standards committee you have to make compromises.) I am also a long-time LLNL employee. Fortran programmers at LLNL have had access to pointers (of the "Cray" pointer flavor) for some 20 or more years and have become strong proponents of dynamically-sized programs. There are extremely few arrays anymore whose sizes are declared at compile time. If LLNL programmers want to change the extents of arrays, they just read different sizes into the executing code; they don't change the values of parameters and recompile before executing the code. I expect Fortran 90 programmers, once they have this facility, will jump on the same bandwagon. Thus you must allow the distribution of dynamic arrays (array pointers) since "static" arrays may cease to exist. I also think that pointer aliases will be heavily used, since triplet notation is hard to read and thus maintain. For example, would you rather see c = a(2:n-1, 2:n-1) * b(2:n-1, 2:n-1) or c = inner_a * inner_b where, of course inner_a => a(2:n-1, 2:n-1) inner_b => b(2:n-1, 2:n-1) Pointer aliases may involve strides, so if the pointer target is distributed, some particular pointer alias may undo the usefulness of the distribution. For example, if you have 32 processors and you distribute on allocation: allocate (x(1:33, 1:33)) corners => x(1:33:32, 1:33:32) corners = corners * two_by_two You may want the ability to redistribute the target or you may assume such usages will be rare and not worth supplying means to make them efficient. It is true that different pointer functionality is needed for use with derived types to create lists, trees, etc. than is needed for arrays, but one of the design criteria for F90 pointers was that there be a single pointer facility that was integrated with both functionalities. In Fortran 90, a structure (object of derived type) is thought of as one (unspecified) storage unit, but if the structure contains a pointer, the target of the pointer could be distributed when it is allocated. Note that structures cannot contain allocatable arrays. In your place, I would ignore allocatable arrays; they provide only a subset of the functionality of pointers. (For this reason, I removed them in my original pointer proposal, but some people felt allocatable arrays were easier to understand than pointers and some vendors had already implemented allocatable arrays, so I was outvoted.) I have joined the hpff-f90 mail group so I will see any subsequent messages, but in any case my address is below. Jeanne Martin jtm@llnl.gov From serafini@ra-iris9.arc.nasa.gov Fri May 8 12:16:09 1992 Received: from ames.arc.nasa.gov by cs.rice.edu (AA00835); Fri, 8 May 92 12:16:09 CDT Received: from ra-iris9.arc.nasa.gov by ames.arc.nasa.gov (5.65c/1.21) with SMTP id AA02271 on Fri, 8 May 1992 10:16:05 -0700 Received: by ra-iris9.arc.nasa.gov (5.52/901025.SGI.UNSUPPORTED.PROTOTYPE) (for @ames.arc.nasa.gov:schreibr@riacs.edu) id AA08984; Fri, 8 May 92 10:15:52 PDT Date: Fri, 8 May 92 10:15:52 PDT Message-Id: <9205081715.AA08984@ra-iris9.arc.nasa.gov> From: David B. Serafini Sender: serafini@ra-iris9.arc.nasa.gov To: halstead@crl.dec.com Cc: schreibr@riacs.edu, halstead@crl.dec.com, hpff-f90@cs.rice.edu, hpff-distribute@cs.rice.edu In-Reply-To: halstead@crl.dec.com's message of Wed, 06 May 92 14:24:16 -0400 <9205061824.AA17751@seine.crl.dec.com> Subject: mapping of pointers Date: Wed, 06 May 92 14:24:16 -0400 From: halstead@crl.dec.com X-Mts: smtp > Date: Wed, 6 May 92 08:45:51 PDT > From: Rob Schreiber > > Dear Mike, > > I think you missed something: > > The allocated data in the application at hand is global. Allocatable > arrays may not be placed in common blocks, pointers may. > > One may use modules, true. > (Modules may or may ot be in the "minimal subset".) > But a second aspect of the application of > David Serafini is the use of a dynamically determined NUMBER > of dynamic arrays. To do this, he allocates an array of pointers, > the size of which is determined at runtime. Then he allocates storage > for each of the allocated pointers. If every one of his allocated > arrays had to have its own name, this would be difficult to do. This last point is certainly true. But I wonder a bit about how you actually construct this object, and how it would relate to the ALIGN/REALIGN syntax that HPF is likely to have: 1. Just creating an array of pointers is moderately challenging. Section 6.2.2 of the Fortran 90 standard states that "An array element ... never has the POINTER attribute." So you can't just declare an array of pointers the way you might in a C program. Presumably you have to define a one-element derived type that contains the pointer, and make an array of those objects. This is basically the method Mike Metcalfe describes in his notes on F90. His example (for those without the notes) TYPE row !declare type REAL, POINTER :: r(:) END TYPE TYPE(row) :: s(n),t(n) !declare arrays do i=1,n ALLOCATE( t(i)%r(1:i) ) !Allocate row i of length i enddo s(i)%r => t(i)%r !equivalent to array assignment `s = t' And the ALIGN implied-DO loop syntax suggested by Joel Williamson (joelw@mozart.convex.com) seems reasonable and sufficient to me to handle this case. In the multi-block algorithm I gave originally as example, alignment between blocks will either be irrelevant (if the cost of exchanging boundary data between blocks is small) or very difficult (if the blocks are different sizes, and the goal is to align at least some of the boundaries to reduce this cost). I don't see why realignment of pointers will be more difficult to implement that alignment of static arrays - you just have to copy the algorithm the compiler uses for static arrays into the run-time library. Making it cheap enough to be worth using is a different problem, though. Maybe I'm missing something important here. -David From schreibr@riacs.edu Tue May 12 12:30:26 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA02990); Tue, 12 May 92 12:30:26 CDT Received: from icarus.riacs.edu by erato.cs.rice.edu (AA10088); Tue, 12 May 92 12:30:23 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA13204; Tue, 12 May 92 10:30:11 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA03119; Tue, 12 May 92 10:29:23 PDT Message-Id: <9205121729.AA03119@thor.riacs.edu> Date: Tue, 12 May 92 10:29:23 PDT From: Rob Schreiber To: hpff-f90@erato.cs.rice.edu Subject: Stor. assoc. Rick Swift and I have been working for a couple of weeks to improve the last draft of the storage/sequence association proposal, based on our discussions at the April meeting and the comments made by the full committee. Key changes: 1. It is simplified along the lines we discussed at the group meeting 2. The possibility that pointers, for example, might not be allowed in data distribution directives leads us to the conclusion that there are sequential and nonsequential variables and common, and that there are distributable and nondistributable variables, and that sequential variables are nondistributable. We hope this is clear in the proposal -- let us know if it is or isnt. 3. Sequence association will require sequential variables in both th caller and the called routines, and this may require modification to existing Fortran 77 codes. Better, we felt, than making variables sequential by default. 4. We dont take a position on Meltzer's proposal, which is, in our new terminology, to allow sequential common blocks to be distributable (as a whole). High Performance Fortran: Storage and Sequence-Association Proposal 1.1 Modification: Original ------- R. Swift: March, 1992. Version 1.0 --- R. Swift: April 10, 1992 Version 1.1 --- R. Schreiber, R. Swift: May 8, 1992 Introduction High Performance Fortran (HPF) proposes to distribute variables across multiple processors in order to help achieve parallel execution performance improvements. Fortran 77 and 90 both specify relationships between the storage for some data elements (via COMMON and EQUIVALENCE), and the order of array elements during association at procedure boundaries (via dummy array arguments). Otherwise, the location of data is not constrained by the language. COMMON and EQUIVALENCE statments constrain the alignment of different data items based on the underlying model of storage units and storage sequences. "Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units." (Standard programming language Fortran ISO/IEC 1539:1991 (E) page 247) The model of storage association is a single linearly addressed memory, based on the traditional SISD processor. It is easy to generate examples where this model can cause gross inefficiencies for architectures where storage for variables is distributed. Sequence association refers to the order of array elements that Fortran requires when an array expression or array element is associated with a dummy array argument that is explicit-shaped or assumed-sized. "The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, ..." (ISO/IEC 1539:1991 (E) page 174) As with storage association, sequence association is based on a linearly addressed memory; it can cause excessive overhead for distributed arrays. Because of the large costs involved in supporting storage and sequence association on distributed-memory architectures, this proposal is based on the idea that neither sequence nor storage association applies to distributed applies. Nevertheless, as an aid to porting Fortran 77 codes, this proposal allows codes that rely on sequence and storage association to be valid in HPF. Some modification to existing Fortran 77 codes *will* be necessary. PROPOSAL I. Definitions De-1. Variables (including scalars and arrays of all types, including derived ones) are either sequential or nonsequential. Sequential variables have the properties of storage association and sequence association. Nonsequential variables do not have the properties of storage association and sequence association. De-2. Common blocks are either sequential or nonsequential. A sequential COMMON block has the properties of storage association and sequence association. A nonsequential COMMON block does not have the properties of storage association or sequence association. De-3. Data distribution attributes are alignment and processor distribution of scalars and array elements in a distributed-memory system. De-4. A variable is distributable or nondistributable. Distributable variables are allowed to appear in HPF explicit distribution directives (EDD): ALIGN, REALIGN, DISTRIBUTE, REDISTRIBUTE, and REDISTRIBUTABLE. De-5. An explicitly distributed variable is any distributable variable that appears in an HPF EDD that specifies its data distribution attributes in the program unit it is declared in. De-6. An implicitly distributed variable is any distributable variable that does not derive its data distribution attributes from any HPF EDD in the program unit it is declared in. End of Definitions Discussion of Definitions. Every variable will have some distribution. A programmer may indicate preferred distributions using directives only for distributable variables. An HPF program may contain both sequential and nonsequential variables and COMMON blocks. It may contain distributable and nondistributable variables. As discussed in Rule St-3 (see Section II) ALL SEQUENTIAL VARIABLES ARE NONDISTRIBUTABLE. The converse may not be true. For example, TARGET variables may be nondistributable, but they do not, by virtue of the TARGET attribute, acquire sequence and storage association properties. There are, therefore, three and only three kinds of variable: Sequential nondistributable, nonsequential nondistributable, and nonsequential distributable. A consequence of Rule St-1 (see Section II) is that sequential COMMON blocks contain only sequential variables and nonsequential COMMON block contain only nonsequential variables. The compiler will insure that sequence and storage association operates correctly for sequential arrays and COMMON blocks by limiting the types of implicit distributions that are employed for them. The situation for COMMON blocks is then: ---------------------------------------------------------------- COMMON BLOCK | Component | Whole Block | Variables | ---------------------------------------------------------------- | | TBD: Sequential | Sequential, | May or may not be | not distributable | permitted in EDDs ---------------------------------------------------------------- | | Nonsequential | Nonsequential, | May not appear in | may be distributable | EDDs ---------------------------------------------------------------- The sequential and distributable attributes are not applicable to templates. Although it is in the province of WG2/3, we recommend *against* requiring that an HPF implementation allow sequential COMMOM blocks to appear in EDDs. This may well be a pessimization tool on many architectures, so if provided, it is better left as a vendor-specific extension. End of Discussion of Definitions II. Storage Association Rule St-1. A variable is SEQUENTIAL if and only if *any* of the following holds: a) it occurs in an EQUIVALENCE statement; b) it is an assumed-size array; c) it is a component of a sequenced type (i.e. a structure with the SEQUENCE attribute); d) it is declared to be sequential in an HPF directive; e) it appears in a sequential COMMON block. Rule St-2. A COMMON block is NONSEQUENTIAL if and only if *all* of the following hold: a) none of its components is a sequential variable; b) it is not declared sequential in an HPF directive; c) it contains the same number of variables in each scoping unit in which the COMMON block is declared, where the shape and type [and explicit data distribution attributes] of corresponding variables of the sequence match. Rule St-3. A sequential variable may not appear in an HPF ALIGN, REALIGN, DISTRIBUTE, REDISTRIBUTE, or REDISTRIBUTABLE directive. (See discussion below for more information.) Rule St-4. The result variable of an array-valued user-written function is a nonsequential array. It may not appear in any HPF SEQUENCE directive. End of Storage Association Discussion of Storage Association A nonsequential COMMON block is a global collection of nonsequential variables. The shape and type of these variables must match in all occurrences of the COMMON block. Whether the distribution attributes need to be identical (no explicit distribution or alignment being one of the possibilities) is a problem for Group 2/3. A COMMON block that appears as a nonsequential COMMON block in one program unit must not appear as a sequential COMMON block in another program unit of the same executable program. When two occurrences of the same COMMON block have components that differ in number, type, or shape, then it is up to the programmer to make all occurrences of the COMMON block appear to be sequential. While it is the province of WG 2/3 to decide this, we believe that any explicitly distributed arrays in a nonsequential COMMON should be required to have identical, static distributions. If not, any subroutine call could cause a redistribution of all arrays in nonsequential COMMON. The same argument leads to the conclusion that global, explicitly distributed arrays in MODULES should not be REDISTRIBUTABLE. By virtue of Rules St-1(e), and Rule St-3, a variable in a sequential COMMON block is nondistributable and may not appear in an EDD. A compiler option (S option) will be provided to make any COMMON block with no explicitly distributed component a sequential COMMON. An alternate option (D option) will be provided to make any COMMON block with no sequential component a nonsequential COMMON. The standard does not specify either as the default. There may well be additional restrictions on distributability, but these are not related to storage or sequence association. For example, it may be determined that POINTER or TARGET variables may not be explicitly distributed. This will *not* imply that variables with the pointer or target attributes are sequential. Thus, COMMON /TRIO/ A(100), B, C POINTER, ARRAY(:) :: B REAL(200,3), TARGET :: C TRIO may be a nonsequential COMMON block, some of whose components may not be allowed in EDDs. Character variables *may* be distributed. See Rule Se-2 below for restrictions. End of Discussion of Storage Association III. Sequence Association Rule Se-1. When an array element or the name of an assumed-size array is used as an actual argument, the associated dummy argument must be a scalar or a sequential array. An array-element designator of a nonsequential array may not be associated with a dummy array argument. Rule Se-2. A character (scalar or array) variable is nonsequential if it conforms to the requirements of Rule St-1. The length of a nonsequential, explicit-length, character dummy argument must be the same as the length of the actual argument. End of Sequence Association Discussion of Sequence Association Change of the length of character variables across a call, as in character (len=100) one_long_word call webster( one_long_word ) subroutine webster( short_dictionary ) character (len=5) short_dictionary( 20 ) is legal in Fortran 77 and Fortran 90. It is allowed provided both actual and dummy are sequential. This may mean that that SEQUENCE directives are needed. Correct Fortran 77 (and henced Fortran 90) codes will require modification according to this proposal. Explicit sequential directives will be needed in some cases where sequence association is required. The ideal method for porting such codes will be to use an array section in the call statement, which will allow both the actual and dummy arrays to be distributable. An alternative would have had all dummy arrays sequential unless explicitly distributed or made nonsequential by directive, as well as all arrays of which an element appears as an actual argument. We hold that this is too conservative and makes it easy to live with bad old code and difficult to write good new code. Another alternative would have allowed sequence association with nonsequential explicit-shape dummy arrays; at runtime the program would detect that an array element was used as the actual argument, and would copy the data into a distributed temporary (if INTENT is not OUT) and copy the data back on return (if INTENT is not IN). This, however, requires that all the dimensions of the explicit-shape dummy match those of the calling routine's array, which will in general cause more data to be copied than is operated on. Consider this Fortran 77 code. SUBROUTINE SWAPROWS(A, LDA, B, LDB, DIM2) REAL A(LDA, DIM2), B(LDB, DIM2) C LDA and LDB specified to allow proper addressing of elements of rows REAL TEMP(DIM2) CHPF ALIGN TEMP(I) WITH A(1,I) TEMP = A(1,:) A(1,:) = B(1,:) B(1,:) = TEMP RETURN END REAL A(1000, 300) CALL SWAPROWS( A(10,1), 1000, A(20,1), 1000, 300) The alternate proposal here causes *all* of A to be copied. This is not viable, and the Fortran 77 style used here needs to be modified. (The example is nonstandard due to aliasing, but typical nevertheless; the same point applies to codes that are legal.) End of Discussion of Sequence Association END OF PROPOSAL Discussion Much of the use of COMMON blocks doesn't really care about storage association; it's an artifact of having no other way to achieve global data prior to Fortran 90. These rules result in a one-time cost of straightening out the COMMON blocks into an admittedly restricted style. By restricting the use of COMMON and EQUIVALENCE in this fashion, Fortran code satisfying these rules is Fortran 90 compatible. Many f77 programs will work; we are only specifying which ones will not. Automatic tools to check COMMON and generate the allowable forms are fairly straightforward. Note that these rules encourage users to utilize MODULEs or the same COMMON block declaration statements in multiple program units via the INCLUDE statement. Thus the straightforward use of HPF data distribution facilities should also help to improve the maintainability and reliability of the code. Rules for mixing nonsequential and sequential variables in the same COMMON block could be made to work, but we doubt that this would be good practice. If we assume the user will rewrite applications once to use HPF, the simpler the rules to follow are the better. Note that the rules of data objects in Modules are simple compared to COMMON, since Modules entail comparatively few storage association problems (Equivalence and ENTRY). Examples: The syntax is illustrative, but the ability to specify each of these attributes is needed. (The SEQUENCE keyword is derived from the Fortran 90 attribute.) To specify a variable is nonsequential but without specifying a distribution: subroutine one(a,b,n,c) dimension a(100), b(N), c(:), d(1000) cHPF NOSEQUENCE :: a,b,c,d To specify explicitly that a variable is sequential: dimension a(100), b(N), c(:), d(1000) cHPF SEQUENCE :: a,b,c,d To specify a COMMON block is nonsequential: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF NOSEQUENCE :: /two/ To specify explicitly that a COMMON block is sequential: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF SEQUENCE :: / two / c If the directive did not appear, /two/ could be c nonsequential by default, depending on the compiler c (S/D) option. In the following, e and f are explicitly distributed, but g is implicitly distributed; two is a nonsequential COMMON block: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF ALIGN e ... cHPF ALIGN f ... Issues: Should argument association between sequential arrays and nonsequential arrays be required? In general, this means some kind of redistribution across the call and back again. If so, redistribution of the dummy can not have a redistribution of the actual as a side effect. We view this as the correct approach (WG 2/3) in any case. From loveman@ftn90.enet.dec.com Tue May 19 13:23:59 1992 Received: from enet-gw.pa.dec.com by cs.rice.edu (AA11418); Tue, 19 May 92 13:23:59 CDT Received: by enet-gw.pa.dec.com; id AA05417; Tue, 19 May 92 11:23:08 -0700 Message-Id: <9205191823.AA05417@enet-gw.pa.dec.com> Received: from ftn90.enet; by decwrl.enet; Tue, 19 May 92 11:23:42 PDT Date: Tue, 19 May 92 11:23:43 PDT From: David Loveman To: hpff-f90@cs.rice.edu, hpff-distribute@cs.rice.edu Cc: loveman@ftn90.enet.dec.com, johnson@rdvax.enet.dec.com Apparently-To: hpff-f90@cs.rice.edu, hpff-distribute@cs.rice.edu Subject: an implementor's request for clarification An Implementor's concerns: Q1: The DECOMPOSITION directive must precede a DISTRIBUTION directive and ALIGN directives when the arrays and decompositions relate to each other? Answer: True False DontKnow Note: Please say True. Example (i) !HPF$ DECOMPOSITION ... decomposition-name ... !HPF$ DISTRIBUTE ... decomposition-name ... !HPF$ ALIGN ... array-name ... decomposition-name ... Q2: Must all f90 declarations for array-name be uttered before an ALIGN directive referring to array-name is seen? Answer: True False DontKnow Notes: One can write in f90 in any order, e.g.: REAL x DIMENSION x(100) Furthermore, COMMON, INTENT, PUBLIC, PRIVATE, ALLOCATABLE, etc., can be written in random order provided that combination of attributes can semantically merge. F90 does have the composite type statement, but F90 allows for specifying the attributes on separate statements, too. We don't want unneeded implementation complexities because of the directives, if possible. Example (ii) !HPF$ ALIGN ... x ... REAL x; DIMENSION x(100) REAL x; DIMENSION x(100) ! this is the only combo !HPF$ ALIGN ... x ... ! I'd like to be okay DIMENSION x(100) !HPF$ ALIGN ... x ... REAL x True False DontKnow Q3: An association directive with an entity-list, e.g., !HPF$ SEQUENCE_ASSOCIATION s must be processed when seen and there can be no f90 declaration statement or ALIGN directive referencing s appearing ahead it. Answer: True False DontKnow Q4: An association directive with no entity-list, e.g., !HPF$ SEQUENCE_ASSOCIATION must appear before any declarations are made? Answer: True False DontKnow SUBROUTINE T(X,Y) !HPF$ SEQUENCE_ASSOCIATION REAL x(100), Y(100) or should it be !HPF$ SEQUENCE_ASSOCIATION ! This in my opinion is SUBROUTINE T(X,Y) ! the correct form REAL x(100), Y(100) but never SUBROUTINE T(X,Y) REAL x(100), Y(100) !HPF$ SEQUENCE_ASSOCIATION Q5: A decomposition-name or a processor-name, i.e., an abstract name from directives, must not be the name of any other entity in a scoping unit (other than the name sharing of COMMON block names that already is in Fortran). Note: Please, please, say true on this one. Answer: True False DontKnow Q6: An align-subscript-name is described as a 'distinct, simple variable name'. Is this the same as the statement: 'an align-subscript-name has the scope of the directive only'? Answer: True False DontKnow Q7: The type of an align-subscript-name is default integer, and the appearance of an align-subscript-name on a type statement has no effect. Answer: True False DontKnow Note: align-subscript-names are akin to implied-do-variables on DATA statements and statement function dummy arguments in that the scope of these guys is that statement only, but appearance of the name on a type statement (assuming it appears ahead) is permitted and honored. Otherwise implicit typing rules are in effect. S1: If Q6 is true, then the statement align-spec-expr is specification-expr -- for ALIGN align-spec-expr is int-expr -- for REALIGN is wrong since an align-spec-expr will contain primaries that are align-subscript-names. Such critters are not allowed either in a specification-expr or an int-expr as defined in the f90 Manual. From zosel@phoenix.ocf.llnl.gov Tue May 19 14:27:19 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA13741); Tue, 19 May 92 14:27:19 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA27395; Tue, 19 May 92 12:27:28 -0700 Date: Tue, 19 May 92 12:27:28 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9205191927.AA27395@phoenix.ocf.llnl.gov> To: hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu, loveman@ftn90.enet.dec.com Subject: Re: an implementor's request for clarification Cc: johnson@rdvax.enet.dec.com One simple reply to Q4 of Loveman's questions ... --- Q4: An association directive with no entity-list, e.g., !HPF$ SEQUENCE_ASSOCIATION must appear before any declarations are made? Answer: True False DontKnow SUBROUTINE T(X,Y) !HPF$ SEQUENCE_ASSOCIATION REAL x(100), Y(100) or should it be !HPF$ SEQUENCE_ASSOCIATION ! This in my opinion is SUBROUTINE T(X,Y) ! the correct form REAL x(100), Y(100) --- OPINION --- the first form is better for those cases where people write simple tools which pull source files apart by subroutines --- directives and comments ahead of the subroutine statement are error prone for correct splitting into multiple files. Yes - good tools have probably solved it, but this is one of those application tools which users tend to reinvent the wheel. -mary- From schreibr@riacs.edu Thu May 21 12:56:37 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA02462); Thu, 21 May 92 12:56:37 CDT Received: from icarus.riacs.edu by erato.cs.rice.edu (AA14524); Thu, 21 May 92 12:56:34 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA22027; Thu, 21 May 92 10:56:34 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA03629; Thu, 21 May 92 10:55:43 PDT Message-Id: <9205211755.AA03629@thor.riacs.edu> Date: Thu, 21 May 92 10:55:43 PDT From: Rob Schreiber To: hpff-f90@erato.cs.rice.edu Subject: Questions Mary, Some questions. 1. Did Rick and I send a "final" draft of the sequence/storage proposal to all? 2. Is it okay? 3. Are we meeting June 8? 4. What is on the agenda? 5. Should we modify our draft to conform with Guy's Group 2/3 draft in a) Names of the sequence_association directives b) explicit distributability of storage_associated common blocks Rob From vinces@pgroup.com Fri May 22 11:29:15 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA14358); Fri, 22 May 92 11:29:15 CDT Received: from bronco.pgroup.com by erato.cs.rice.edu (AA14810); Fri, 22 May 92 11:29:09 CDT Received: by bronco.pgroup.com id AA11464 (5.65c/IDA-1.4.4 for hpff-f90@erato.cs.rice.edu); Fri, 22 May 1992 09:34:36 -0700 Date: Fri, 22 May 1992 09:34:36 -0700 From: Vince Schuster Message-Id: <199205221634.AA11464@bronco.pgroup.com> To: hpff-f90@erato.cs.rice.edu Subject: Re: Questions Rick, Regarding the final draft, are you refering to the May 12 email? With the May 8 Version 1.1? I assumed we are meeting on June 8. I assumed part of the agenda would be to discuss the draft. Does this include details regarding Loveman's questions? vince schuster (vinces@pgroup.com) From gls@think.com Tue May 26 14:24:43 1992 Received: from mail.think.com (Mail1.Think.COM) by cs.rice.edu (AA20612); Tue, 26 May 92 14:24:43 CDT Return-Path: Received: from Strident.Think.COM by mail.think.com; Tue, 26 May 92 15:24:03 -0400 From: Guy Steele Received: by strident.think.com (4.1/Think-1.0C) id AA10711; Tue, 26 May 92 15:23:54 EDT Date: Tue, 26 May 92 15:23:54 EDT Message-Id: <9205261923.AA10711@strident.think.com> To: loveman@ftn90.enet.dec.com Cc: hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu, loveman@ftn90.enet.dec.com In-Reply-To: David Loveman's message of Tue, 26 May 92 08:34:13 PDT <9205261533.AA11028@enet-gw.pa.dec.com> Subject: Resend of "an implementor's request for clarification" Date: Tue, 26 May 92 08:34:13 PDT From: David Loveman Apparently-To: hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu . . . . . An Implementor's concerns: Q1: The DECOMPOSITION directive must precede a DISTRIBUTION directive and ALIGN directives when the arrays and decompositions relate to each other? Answer: True False DontKnow Note: Please say True. False. Seems to me that it would be consistent with Fortran 90 to adopt that attitude that if a name appears before its type has been established, then the type of that name is established by the implicit typing rules then in effect, and any following declaration must confirm that type. Example (i) !HPF$ DECOMPOSITION ... decomposition-name ... !HPF$ DISTRIBUTE ... decomposition-name ... !HPF$ ALIGN ... array-name ... decomposition-name ... To be more specific: !HPF$ DISTRIBUTE BROWNIE_POINTS(*) ONTO SYCOPHANTS The implicit typing declarations would establish BROWNIE_POINTS as having type REAL, and an error would then ensue because it ought to be of type TEMPLATE. (If, however, in a distant future we were to permit IMPLICIT TEMPLATE(B) then BROWNIE_POINTS would then have implicit type TEMPLATE, which might be confirmed by a subsequent TEMPLATE definition.) The same comments apply to SYCOPHANTS: the implicit typing rules would make it of type REAL when it ought to be of type PROCESSORS, so in practice you would get an error. So the answer to your question is "true" in the absence of IMPLICIT TEMPLATE, but "false" when looking forward to a more general hypothetical future where HPF is absorbed into Fortran 90. Q2: Must all f90 declarations for array-name be uttered before an ALIGN directive referring to array-name is seen? Answer: True False DontKnow Notes: One can write in f90 in any order, e.g.: REAL x DIMENSION x(100) Furthermore, COMMON, INTENT, PUBLIC, PRIVATE, ALLOCATABLE, etc., can be written in random order provided that combination of attributes can semantically merge. F90 does have the composite type statement, but F90 allows for specifying the attributes on separate statements, too. We don't want unneeded implementation complexities because of the directives, if possible. Example (ii) !HPF$ ALIGN ... x ... REAL x; DIMENSION x(100) REAL x; DIMENSION x(100) ! this is the only combo !HPF$ ALIGN ... x ... ! I'd like to be okay DIMENSION x(100) !HPF$ ALIGN ... x ... REAL x True False DontKnow Again, to be consistent with a Fortran 90 future, I would say "false". "ALIGN" is just another attribute. Of course, if "x" first appears in an ALIGN statement, its type will be established by implicit typing rules and can only be confirmed by a subsequent type statement. Q3: An association directive with an entity-list, e.g., !HPF$ SEQUENCE_ASSOCIATION s must be processed when seen and there can be no f90 declaration statement or ALIGN directive referencing s appearing ahead it. Answer: True False DontKnow Is SEQUENCE_ASSOCIATION to be considered an attribute? Do you envision being able to say INTEGER,DIMENSION(100),SEQUENCE_ASSOCIATION::P,Q,R ? Q4: An association directive with no entity-list, e.g., !HPF$ SEQUENCE_ASSOCIATION must appear before any declarations are made? Answer: True False DontKnow SUBROUTINE T(X,Y) !HPF$ SEQUENCE_ASSOCIATION REAL x(100), Y(100) or should it be !HPF$ SEQUENCE_ASSOCIATION ! This in my opinion is SUBROUTINE T(X,Y) ! the correct form REAL x(100), Y(100) but never SUBROUTINE T(X,Y) REAL x(100), Y(100) !HPF$ SEQUENCE_ASSOCIATION The problem is that a program unit currently must begin with a SUBROUTINE or FUNCTION statement or perhaps a PROGRAM statement. Maybe you just have to use the entity-list form to disavow sequence association for dummies. Or maybe we make a weird exception if the entity-list-less form immediately follows a SUBROUTINE, FUNCTION, or PROGRAM statement. Q5: A decomposition-name or a processor-name, i.e., an abstract name from directives, must not be the name of any other entity in a scoping unit (other than the name sharing of COMMON block names that already is in Fortran). Note: Please, please, say true on this one. Answer: True False DontKnow True. Q6: An align-subscript-name is described as a 'distinct, simple variable name'. Is this the same as the statement: 'an align-subscript-name has the scope of the directive only'? Answer: True False DontKnow False; the two statements are not the same. However, I think that both statements are intended to be true. Q7: The type of an align-subscript-name is default integer, and the appearance of an align-subscript-name on a type statement has no effect. Answer: True False DontKnow Note: align-subscript-names are akin to implied-do-variables on DATA statements and statement function dummy arguments in that the scope of these guys is that statement only, but appearance of the name on a type statement (assuming it appears ahead) is permitted and honored. Otherwise implicit typing rules are in effect. True. S1: If Q6 is true, then the statement align-spec-expr is specification-expr -- for ALIGN align-spec-expr is int-expr -- for REALIGN is wrong since an align-spec-expr will contain primaries that are align-subscript-names. Such critters are not allowed either in a specification-expr or an int-expr as defined in the f90 Manual. Right; so we'll have to fix that. --Guy From loveman@ftn90.enet.dec.com Fri May 29 13:13:10 1992 Received: from enet-gw.pa.dec.com by cs.rice.edu (AA05763); Fri, 29 May 92 13:13:10 CDT Received: by enet-gw.pa.dec.com; id AA10051; Fri, 29 May 92 11:11:09 -0700 Message-Id: <9205291811.AA10051@enet-gw.pa.dec.com> Received: from ftn90.enet; by decwrl.enet; Fri, 29 May 92 11:11:25 PDT Date: Fri, 29 May 92 11:11:25 PDT From: David Loveman To: hpff-f90@cs.rice.edu Cc: loveman@ftn90.enet.dec.com Apparently-To: hpff-f90@cs.rice.edu Subject: Subset High Performance Fortran It may not be correct, but it *will* generate some discussion. -David ----------------------------------------------------------------------- Proposal for Subset HPF David Loveman Digital Equipment Corporation Version of May 29, 1992 1. OVERVIEW High Performance Fortran is being defined as full Fortran 90 augmented by language features in three areas: 7 directives in the form of structured comments which, although they do not change the meaning of a program, provide information to a compiler to enable optimization, 7 a FORALL statement, and 7 new intrinsic functions. This proposal presents a subset of HPF capable of being implemented by multiple implementors more rapidly than the full HPF. It is intended that such a subset implementation be to provide a standard interim capability and that full HPF implementations should be developed as rapidly as possible. 2. FORTRAN 90 The facilities for array computations in Fortran 90 will make it the programming language of choice for scientific and engineering numerical calculations on high performance computers. Indeed, some of these facilities are already supported in compilers from a number of vendors. The introductory overview in the Fortran 90 standard states: Operations for processing whole arrays and subarrays (array sections) are included in [Fortran 90] for two principal reasons: (1) these features provide a more concise and higher level language that will allow programmers more quickly and reliably to develop and maintain scientific/engineering applications, and (2) these features can significantly facilitate optimization of array operations on many computer architectures. Other features of Fortran 90 that improve upon the features provided in FORTRAN are: 7 Additional storage classes of objects --- The new storage classes such as allocatable, automatic, and assumed-shape objects, and the pointer facility of Fortran 90 add significantly to those of FORTRAN 77 and should reduce the style of use of FORTRAN 77 constructs which can lead to less than full computational speed on high performance computers, such as EQUIVALENCEd array objects, COMMON definitions with non-identical array definitions across subprograms, and actual-argument/dummy-argument array shape transformations. 7 Modules --- The module facilities of Fortran 90 enable the practice of design implementation using data abstractions. These facilities support the specification of modules, including user-defined data types and structures, defined operators on those types, and generic procedures for implementing common algorithms to be used on a variety of data structures. In addition to modules, the definition of interface blocks enables the application programmer to specify the interfaces subprograms explicitly, allowing a high quality compiler to use the information specified to provide better checking and optimization at the interface to other subprograms. 7 Additional intrinsic procedures --- Fortran 90 includes the definition of a large number of new intrinsic procedures. Many of these new intrinsic procedures support mathematical operations on arrays, including the construction and transformation of arrays. Also, there are numerical accuracy intrinsic procedures designed to support numerical programming, and bit manipulation intrinsic procedures derived from MIL-STD-1753. Over time, High Performance Fortran will be fully Fortran 90 conformant. Because the effort involved in producing a full Fortran 90 compiler, High Performance Fortran is defined at two levels: Subset High Performance Fortran and full High Performance Fortran. Subset High Performance Fortran is a subset of Fortran 90 with a subset of the HPF additional language features. High Performance Fortran is full Fortran 90 with all of the approved HPF language features. 3. FORTRAN 90 FEATURES IN SUBSET HIGH PERFORMANCE FORTRAN 7 FORTRAN 77 standard conformant, except for sequence and storage association 7 MIL-STD-1753 conformance  DO WHILE statement  END DO statement  IMPLICIT NONE statement  INCLUDE statement (line)  scalar bit manipulation intrinsic functions: IOR, IAND, NOT, IEOR, ISHFT, ISHFTC, BTEST, IBSET, IBCLR, IBITS, MVBITS  octal and hexadecimal constants for use in DATA statements: O'. . .', Z'. . . ' 7 arithmetic and logical array features  array sections > subscript triplet notation > vector-valued subscripts  array constructors  arithmetic and logical operations on whole arrays and array sections  array assignment  masked array assignment > WHERE statement > block WHERE . . . ELSEWHERE construct  array-valued external functions  AUTOMATIC arrays  ALLOCATABLE arrays and the ALLOCATE and DEALLOCATE statements  assumed-shape arrays 7 inquiry, elemental, and transformational intrinsic functions  argument presence inquiry function: PRESENT  numeric scalar and array elemental functions: ABS, AIMAG, AINT, ANINT, CEILING, CMPLX, CONJG, DBLE, DIM, DPROD, FLOOR, INT, MAX, MIN, MOD, MODULO, NINT, REAL, SIGN  mathematical scalar and array elemental functions: ACOS, ASIN, ATAN, ATAN2, COS, COSH, EXP, LOG, LOG10, SIN, SINH, SQRT, TAN, TANH  character scalar functions: CHAR, ICHAR, INDEX, LGE, LGT, LLE, LLT  character inquiry function: LEN  kind functions: KIND, SELECTED_INT_KIND, SELECTED_REAL_KIND  bit manipulation functions (the MIL-STD-1753 functions): BTEST, IAND, IBCLR, IBITS, IBSET, IEOR, IOR, ISHFT, ISHFTC, NOT  vector and matrix multiply functions: DOT_PRODUCT, MATMUL  array reduction functions: ALL, ANY, COUNT, MAXVAL, MINVAL, PRODUCT, SUM  array inquiry functions: ALLOCATED, LBOUND, SHAPE, SIZE, UBOUND  array construction functions: MERGE, PACK, SPREAD, UNPACK  array reshape function: RESHAPE  array manipulation functions: CSHIFT, EOSHIFT, TRANSPOSE  array location functions: MAXLOC, MINLOC  intrinsic subroutines: the MIL-STD-1753 subroutines MVBITS, RANDOM_NUMBER 7 control statements  CASE  DO loop extensions > "DO forever" > CYCLE > EXIT 7 declarations  object-oriented syntax > object-oriented DATA statement > specification attributes: DATA, DIMENSION, INTENT, OPTIONAL, PARAMETER, SAVE, KIND selector  attribute specification statements: INTENT, OPTIONAL, PARAMETER, SAVE 7 procedure features  INTERFACE blocks  optional arguments  keyword argument passage 7 syntax improvements  long (31 character) names  lower case letters  use of "_" in names  binary constants for use in DATA statements - B'. . .'  " delimiter for character strings in addition to ' delimiter  "!" initiated comments, both full line and trailing  relational operators: <, <=, ==, /=, >, >=  named IF, CASE, DO constructs  optional "construct-name name" on END statement for PROGRAM, BLOCK DATA, FUNCTION, and SUBROUTINE 7 KIND capability - only standard way to get COMPLEX*16  KIND type parameters  KIND-qualified literals  KIND intrinsics 4. FORTRAN 90 FEATURES NOT IN SUBSET HIGH PERFORMANCE FORTRAN 7 sequence and storage association 7 assumed size arrays 7 free form source input 7 CHARACTER array operations 7 recursive procedures 7 Fortran 90 pointers 7 modules and the USE statement 7 user-defined derived types (i.e., record structures) 7 internal procedures 7 generic and defined operators 7 Fortran 90 non-FORTRAN 77 input / output facilities including NAMELIST 7 intrinsic functions not in High Performance Fortran  character scalar functions: ACHAR, ADJUSTL, ADJUSTR, IACHAR, LEN_TRIM, REP, SCAN, TRIM, VERIFY  logical function: LOGICAL  numeric inquiry functions: DIGITS, EPSILON, HUGE, MAXEXPONENT, MINEXPONENT, PRECISION, RADIX, RANGE, TINY  bit inquiry function: BIT_SIZE  transfer: TRANSFER  floating point manipulation functions: EXPONENT, FRACTION, SCALE, SET_EXPONENT, NEAREST, RRSPACING, SPACING  pointer association status inquiry function: ASSOCIATED  intrinsic subroutines: DATE_AND_TIME, RANDOM_SEED, SYSTEM_CLOCK 5. HPF FEATURES IN SUBSET HIGH PERFORMANCE FORTRAN In the absence of any approved HPF features, the list of features in Subset High Performance Fortran can only be suggestive. 7 "Specification" HPF directives 7 FORALL  single assignment statement FORALL  multiple assignment statement FORALL 7 NUMBER_OF_PROCESSORS and PROCESSOR_SHAPE intrinsics 6. HPF FEATURES NOT IN SUBSET HIGH PERFORMANCE FORTRAN In the absence of any approved HPF features, the list of features not in Subset High Performance Fortran can only be suggestive. 7 "Executable" HPF directives 7 FORALL with other than assignment statements 7 The other intrinsic functions - ------- End of Unsent Draft ------- End of Forwarded Message From meltzer@tamarack.cray.com Fri May 29 14:19:54 1992 Received: from timbuk.cray.com by cs.rice.edu (AA08753); Fri, 29 May 92 14:19:54 CDT Received: from willow14.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6af) id AA04976; Fri, 29 May 92 14:19:54 CDT Received: by willow14.cray.com id AA19438; 4.1/CRI-5.6; Fri, 29 May 92 14:19:52 CDT Date: Fri, 29 May 92 14:19:52 CDT From: meltzer@tamarack.cray.com (Andy Meltzer) Message-Id: <9205291919.AA19438@willow14.cray.com> To: hpff-f90@cs.rice.edu Subject: Re: Draft Proposal on Sequence and Storage Association > Modification: Original ------- R. Swift: March, 1992. > Version 1.0 --- R. Swift: April 10, 1992 > Version 1.1 --- R. Schreiber, R. Swift: May 8, 1992 I'm not sure exactly what is different here, it seems that it has just been cleaned up some. Are there any substantial changes? > The compiler will insure that sequence and storage association > operates correctly for sequential arrays and COMMON blocks by > limiting the types of implicit distributions that are employed > for them. This is a very limiting way to ensure that sequence and storage association operate correctly. It is mandating an implementation. Can't we just say that "the compiler will ensure that sequence and storage association operate correctly" without telling the compiler how to do so? My proposal (sent out about a month ago) details a way to do this. I again want to point out that where we need not mandate limitations to the user community, we should not do so. The conservative approach is not to restrict these behaviors, it is to allow them, but to warn the user that (like many other directives) some sequence and storage association distribution directives might be ignored by some compilers. A compiler might also warn that potential non-high-performance behavior might result. Furthermore, by the definitions put forward here, any compiler which decides to extend the availability of sequence and storage association is in violation of the specification, rather than extending it. Again, please consider my proposed extension to this draft. Andy Meltzer From shapiro@think.com Fri May 29 14:27:47 1992 Received: from mail.think.com (Mail1.Think.COM) by cs.rice.edu (AA09029); Fri, 29 May 92 14:27:47 CDT Return-Path: Received: from Django.Think.COM by mail.think.com; Fri, 29 May 92 15:27:43 -0400 From: Richard Shapiro Received: by django.think.com (4.1/Think-1.2) id AA03180; Fri, 29 May 92 15:27:42 EDT Date: Fri, 29 May 92 15:27:42 EDT Message-Id: <9205291927.AA03180@django.think.com> To: loveman@ftn90.enet.dec.com Cc: hpff-f90@cs.rice.edu In-Reply-To: David Loveman's message of Fri, 29 May 92 11:11:25 PDT <9205291811.AA10051@enet-gw.pa.dec.com> Subject: Subset High Performance Fortran The proposal was pretty long, so I won't include it again. I think it's a good suggested subset overall. The only thing I would like to see is that NAMELIST i/o be in the subset. I'm not too concerned about its absence, however, since I expect most vendors to have it anyway. Richard Shapiro, United Technologies Corporation (shapiro@think.com) From loveman@ftn90.enet.dec.com Fri May 29 14:52:58 1992 Received: from enet-gw.pa.dec.com by cs.rice.edu (AA10017); Fri, 29 May 92 14:52:58 CDT Received: by enet-gw.pa.dec.com; id AA17197; Fri, 29 May 92 12:50:18 -0700 Message-Id: <9205291950.AA17197@enet-gw.pa.dec.com> Received: from ftn90.enet; by decwrl.enet; Fri, 29 May 92 12:50:38 PDT Date: Fri, 29 May 92 12:50:38 PDT From: David Loveman To: hpff-f90@cs.rice.edu Cc: loveman@ftn90.enet.dec.com Apparently-To: hpff-f90@cs.rice.edu Subject: Subset High Performance Fortran It may not be correct, but it *will* generate some discussion. -David ------------------------------------------------------------------------ Proposal for Subset HPF David Loveman Digital Equipment Corporation Version of May 29, 1992 1. OVERVIEW High Performance Fortran is being defined as full Fortran 90 augmented by language features in three areas: 7 directives in the form of structured comments which, although they do not change the meaning of a program, provide information to a compiler to enable optimization, 7 a FORALL statement, and 7 new intrinsic functions. This proposal presents a subset of HPF capable of being implemented by multiple implementors more rapidly than the full HPF. It is intended that such a subset implementation be to provide a standard interim capability and that full HPF implementations should be developed as rapidly as possible. 2. FORTRAN 90 The facilities for array computations in Fortran 90 will make it the programming language of choice for scientific and engineering numerical calculations on high performance computers. Indeed, some of these facilities are already supported in compilers from a number of vendors. The introductory overview in the Fortran 90 standard states: Operations for processing whole arrays and subarrays (array sections) are included in [Fortran 90] for two principal reasons: (1) these features provide a more concise and higher level language that will allow programmers more quickly and reliably to develop and maintain scientific/engineering applications, and (2) these features can significantly facilitate optimization of array operations on many computer architectures. Other features of Fortran 90 that improve upon the features provided in FORTRAN are: 7 Additional storage classes of objects --- The new storage classes such as allocatable, automatic, and assumed-shape objects, and the pointer facility of Fortran 90 add significantly to those of FORTRAN 77 and should reduce the style of use of FORTRAN 77 constructs which can lead to less than full computational speed on high performance computers, such as EQUIVALENCEd array objects, COMMON definitions with non-identical array definitions across subprograms, and actual-argument/dummy-argument array shape transformations. 7 Modules --- The module facilities of Fortran 90 enable the practice of design implementation using data abstractions. These facilities support the specification of modules, including user-defined data types and structures, defined operators on those types, and generic procedures for implementing common algorithms to be used on a variety of data structures. In addition to modules, the definition of interface blocks enables the application programmer to specify the interfaces subprograms explicitly, allowing a high quality compiler to use the information specified to provide better checking and optimization at the interface to other subprograms. 7 Additional intrinsic procedures --- Fortran 90 includes the definition of a large number of new intrinsic procedures. Many of these new intrinsic procedures support mathematical operations on arrays, including the construction and transformation of arrays. Also, there are numerical accuracy intrinsic procedures designed to support numerical programming, and bit manipulation intrinsic procedures derived from MIL-STD-1753. Over time, High Performance Fortran will be fully Fortran 90 conformant. Because the effort involved in producing a full Fortran 90 compiler, High Performance Fortran is defined at two levels: Subset High Performance Fortran and full High Performance Fortran. Subset High Performance Fortran is a subset of Fortran 90 with a subset of the HPF additional language features. High Performance Fortran is full Fortran 90 with all of the approved HPF language features. 3. FORTRAN 90 FEATURES IN SUBSET HIGH PERFORMANCE FORTRAN 7 FORTRAN 77 standard conformant, except for sequence and storage association 7 MIL-STD-1753 conformance  DO WHILE statement  END DO statement  IMPLICIT NONE statement  INCLUDE statement (line)  scalar bit manipulation intrinsic functions: IOR, IAND, NOT, IEOR, ISHFT, ISHFTC, BTEST, IBSET, IBCLR, IBITS, MVBITS  octal and hexadecimal constants for use in DATA statements: O'. . .', Z'. . . ' 7 arithmetic and logical array features  array sections > subscript triplet notation > vector-valued subscripts  array constructors  arithmetic and logical operations on whole arrays and array sections  array assignment  masked array assignment > WHERE statement > block WHERE . . . ELSEWHERE construct  array-valued external functions  AUTOMATIC arrays  ALLOCATABLE arrays and the ALLOCATE and DEALLOCATE statements  assumed-shape arrays 7 inquiry, elemental, and transformational intrinsic functions  argument presence inquiry function: PRESENT  numeric scalar and array elemental functions: ABS, AIMAG, AINT, ANINT, CEILING, CMPLX, CONJG, DBLE, DIM, DPROD, FLOOR, INT, MAX, MIN, MOD, MODULO, NINT, REAL, SIGN  mathematical scalar and array elemental functions: ACOS, ASIN, ATAN, ATAN2, COS, COSH, EXP, LOG, LOG10, SIN, SINH, SQRT, TAN, TANH  character scalar functions: CHAR, ICHAR, INDEX, LGE, LGT, LLE, LLT  character inquiry function: LEN  kind functions: KIND, SELECTED_INT_KIND, SELECTED_REAL_KIND  bit manipulation functions (the MIL-STD-1753 functions): BTEST, IAND, IBCLR, IBITS, IBSET, IEOR, IOR, ISHFT, ISHFTC, NOT  vector and matrix multiply functions: DOT_PRODUCT, MATMUL  array reduction functions: ALL, ANY, COUNT, MAXVAL, MINVAL, PRODUCT, SUM  array inquiry functions: ALLOCATED, LBOUND, SHAPE, SIZE, UBOUND  array construction functions: MERGE, PACK, SPREAD, UNPACK  array reshape function: RESHAPE  array manipulation functions: CSHIFT, EOSHIFT, TRANSPOSE  array location functions: MAXLOC, MINLOC  intrinsic subroutines: the MIL-STD-1753 subroutines MVBITS, RANDOM_NUMBER 7 control statements  CASE  DO loop extensions > "DO forever" > CYCLE > EXIT 7 declarations  object-oriented syntax > object-oriented DATA statement > specification attributes: DATA, DIMENSION, INTENT, OPTIONAL, PARAMETER, SAVE, KIND selector  attribute specification statements: INTENT, OPTIONAL, PARAMETER, SAVE 7 procedure features  INTERFACE blocks  optional arguments  keyword argument passage 7 syntax improvements  long (31 character) names  lower case letters  use of "_" in names  binary constants for use in DATA statements - B'. . .'  " delimiter for character strings in addition to ' delimiter  "!" initiated comments, both full line and trailing  relational operators: <, <=, ==, /=, >, >=  named IF, CASE, DO constructs  optional "construct-name name" on END statement for PROGRAM, BLOCK DATA, FUNCTION, and SUBROUTINE 7 KIND capability - only standard way to get COMPLEX*16  KIND type parameters  KIND-qualified literals  KIND intrinsics 4. FORTRAN 90 FEATURES NOT IN SUBSET HIGH PERFORMANCE FORTRAN 7 sequence and storage association 7 assumed size arrays 7 free form source input 7 CHARACTER array operations 7 recursive procedures 7 Fortran 90 pointers 7 modules and the USE statement 7 user-defined derived types (i.e., record structures) 7 internal procedures 7 generic and defined operators 7 Fortran 90 non-FORTRAN 77 input / output facilities including NAMELIST 7 intrinsic functions not in High Performance Fortran  character scalar functions: ACHAR, ADJUSTL, ADJUSTR, IACHAR, LEN_TRIM, REP, SCAN, TRIM, VERIFY  logical function: LOGICAL  numeric inquiry functions: DIGITS, EPSILON, HUGE, MAXEXPONENT, MINEXPONENT, PRECISION, RADIX, RANGE, TINY  bit inquiry function: BIT_SIZE  transfer: TRANSFER  floating point manipulation functions: EXPONENT, FRACTION, SCALE, SET_EXPONENT, NEAREST, RRSPACING, SPACING  pointer association status inquiry function: ASSOCIATED  intrinsic subroutines: DATE_AND_TIME, RANDOM_SEED, SYSTEM_CLOCK 5. HPF FEATURES IN SUBSET HIGH PERFORMANCE FORTRAN In the absence of any approved HPF features, the list of features in Subset High Performance Fortran can only be suggestive. 7 "Specification" HPF directives 7 FORALL  single assignment statement FORALL  multiple assignment statement FORALL 7 NUMBER_OF_PROCESSORS and PROCESSOR_SHAPE intrinsics 6. HPF FEATURES NOT IN SUBSET HIGH PERFORMANCE FORTRAN In the absence of any approved HPF features, the list of features not in Subset High Performance Fortran can only be suggestive. 7 "Executable" HPF directives 7 FORALL with other than assignment statements 7 The other intrinsic functions From zosel@phoenix.ocf.llnl.gov Tue Jun 2 11:37:23 1992 Received: from rice.edu ([128.42.5.1]) by cs.rice.edu (AA05866); Tue, 2 Jun 92 11:37:23 CDT Received: from phoenix.ocf.llnl.gov ([134.9.48.6]) by rice.edu (AA06295); Tue, 2 Jun 92 11:36:39 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA16730; Tue, 2 Jun 92 09:37:37 -0700 Date: Tue, 2 Jun 92 09:37:37 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9206021637.AA16730@phoenix.ocf.llnl.gov> To: hpff-f90@rice.edu Subject: subgroup meeting Fortran 90 Subgroup (Group 1) HPF Meeting Agenda June 8, 1992 Starting time: We will try for 1:30 PM, however, this is tight for some west coast arrivals. (Maybe people who want lunch can arrange for "take-out" or "room service" to the meeting room if they arrive late.) Draft Agenda: (Please send suggested changes) (1) The Vector Language Subset Proposal. (We are scheduled to present this to the full committee at this meeting.) (2) User Feedback about restrictions on Common Blocks (3) Distributed Common Blocks (4) Storage Association Proposal (5) CHARACTER - (anything to report?) (6) POINTER - (any summary recommendation of the email discussion?) (7) Summarize any directives we are proposing. (8) Other Issues? ---- comments / additions / changes welcome I hope to have a Mac Powerbook at the meeting - and there will be a printer available, so please bring diskettes with proposal texts in case we want to modify them. If they are short, we can print them directly. If they are long, perhaps we can locate a copy shop and make a run for last minute changes. -mary- From shapiro@think.com Tue Jun 2 12:54:00 1992 Received: from rice.edu ([128.42.5.1]) by cs.rice.edu (AA08321); Tue, 2 Jun 92 12:54:00 CDT Received: from mail.think.com (Mail1.Think.COM) by rice.edu (AA07002); Tue, 2 Jun 92 12:53:16 CDT Return-Path: Received: from Django.Think.COM by mail.think.com; Tue, 2 Jun 92 13:53:55 -0400 From: Richard Shapiro Received: by django.think.com (4.1/Think-1.2) id AA14057; Tue, 2 Jun 92 13:53:54 EDT Date: Tue, 2 Jun 92 13:53:54 EDT Message-Id: <9206021753.AA14057@django.think.com> To: hpff-f90@rice.edu Subject: Survey results concerning some F90 issues. I sent out a brief survey to Fortran users at both United Technologies Research Center and Thinking Machines. The survey is below: ----------------------------------------------------------------------- As part of the High Performance Fortran Forum, I've been asked to survey users as to how they feel about certain aspects of the language. Please give me feedback. Issue #1: Character data. How important is it to you for HPF to support parallel operations on character data? CM Fortran, for example, does not support parallel operations on character data. Issue #2: Sequence association How important is it to you for HPF to support sequence association on distributed data (sequence association is that property of an array which specifies the order in which array elements are stored in memory, and allows one to reshape arrays through subroutine calls, for example)? CM Fortran does not support sequence association on distributed arrays. If sequence association should be supported, what should the default for a distributed array be? In otherwords, if unspecified, should the compiler assume that an array is sequence associated or not sequence associated. Issue #3: Storage association How important is it to you for HPF to support storage association on distributed COMMON blocks? If storage association should be supported, what should the default for a COMMON block be? An example of storage association: In subroutine1: COMMON /FOO/ A(100),B(100) In subroutine2: COMMON /FOO/ C(200) C(101) refers to the same memory as B(1). Thank you in advance for taking the time to respond. Richard Shapiro, United Technologies Corporation (shapiro@think.com) ---------------------------------------------------------------------- Here is a summary of the responses: I got responses from 4 people at UTRC (all users, counting myself), and 7 people at Thinking Machines (2 compiler developers, 5 users). Issue #1: CHARACTER data 2 would like it, 6 don't care. Issue #2: Sequence association 5 would like it, 2 don't care. Of the responders, 3 think the default should be no sequence associated, 1 thinks the default should be sequence associated. Issue #3: Storage association 6 would like it, 3 don't care. Of the responders, 3 thinks the default should be not storage associated, 2 think the default should be storage associated. --------------------------------------------------------------------- The actual responses follow: Date: Mon, 11 May 92 11:58:09 -0400 From: bnmc@utrccm.res.utc.com (Brice Cassenti) Rich, below are my thoughts on your little survey. Brice Issue #1: Character data : Not important Issue #2: Sequence association : Improtant. The default should be no sequence associated Issue #3: Storage association : Not important ----------------------------------------------------------------------------- Date: Wed, 6 May 92 16:29:17 EDT From: Doug MacDonald Sender: macdon@Think.COM To: shapiro@Think.COM In-Reply-To: Richard Shapiro's message of Wed, 6 May 92 15:48:07 EDT <9205061948.AA03062@zydeco.think.com> Subject: A little opinion survey Issue #1: Character data. How important is it to you for HPF to support parallel operations on character data? CM Fortran, for example, does not support parallel operations on parallel data. Not. I can't see HPF being used as an implementation language for database projects, can you? Issue #2: Sequence association I don't understand what this means. If CM Fortran doesn't support it, it's obviously not array layout. Is there anything on line that I can read to get the definition? Issue #3: Storage association How important is it to you for HPF to support storage association on distributed COMMON blocks? This seems like a very good idea. If storage association should be supported, what should the default for a COMMON block be? Do you mean, should the COMMON blocks below, if in different procedures or block data programs, refer to the same memory by default? Yes. ----------------------------------------------------------------------------- Date: Wed, 6 May 92 15:30:16 CDT From: alk@wt.msc.edu (Anthony L. Kimball) Issue #1: Character data. Not. Give me structures first. Issue #2: Sequence association This explanation of sequence association is completely opaque to me. Issue #3: Storage association It is evil. I can't tell you how many wasted hours I've spent on such code (written by maniacs). ----------------------------------------------------------------------------- From: Woody Lichtenstein Date: Wed, 6 May 92 16:35:46 EDT Subject: A little opinion survey It is possible to support a notion of sequence association within local memory without full global sequence association. Local sequence association is useful for programming and need not have any performance impact. ----------------------------------------------------------------------------- From: Alex Vasilevsky Issue #1: Character data. What do you mean by parallel operations on characters? Do you mean that array operations on characters should be parallelized by the compiler? If so, what does that have to do with language defining something to be parallel? The semantics of the language that will run on workstations should not define anything to be explicitly parallel. Issue #2: Sequence association Yes, it should be supported for distributed arrays completly across the machine, and not partially. The compiler can linearize the array and make it all work, albeit slow on some computers. It should only be supported as compatibility with full F90 or scalar codes. The switch that specifies the sequence association should be on by default. The user should have the ability to turn this off. Issue #3: Storage association Important. If storage association should be supported, what should the default for a COMMON block be? Yes. Default same as sequence associtaion. All codes written in F77 must work in this language, and since all of F77 is in HPF then it *must* support standard F77 semantics on memory. There should be a capability build into the language through directes or whatever elese, that allow one to go away from Fortran 77 memory model. -Alex V. ----------------------------------------------------------------------------- From: Robert Ferrell Issue #1: Character data. Not important. Issue #2: Sequence association This would be nice mostly for existing codes. I do not think I would use this feature in new codes, since sequence association is often used for memory management, and there are much better memory management techniques available. If sequence association should be supported, what should the default for a distributed array be? In otherwords, if unspecified, should the compiler assume that an array is sequence associated or not sequence associated. Not sequence associated. Issue #3: Storage association Same as above- important only for old codes. If storage association should be supported, what should the default for a COMMON block be? Not storage associated. ----------------------------------------------------------------------------- From: Bernie Murray Issue #1: Character data. I wish I had this before, I'm sure I'll want to use it in the future. Is there some big problem implementing this on the cm5 ? Issue #2: Sequence association This sounds handy. I like optional user control. Your fault, my fault, default, doesn't matter to me. Issue #3: Storage association I've gone thru a lot of hassles to get storage association tricks to work in other languages. Why not make it easy on me. It's always easy to ask for further fugacious future features. Bernie ----------------------------------------------------------------------------- Date: Thu, 7 May 92 08:48:55 -0600 From: goldy@capitol.ucar.edu (Steve Goldhaber) All three of the proposed features would make life easier for porting codes to parallel machines. In addition, the sequence association feature would make some optimizations more clear. I would vote fairly strongly for all three although their absence hasn't been as bad as things like nested where statements and lack of I/O support. ----------------------------------------------------------------------------- Date: Thu, 7 May 92 16:28:43 -0400 From: bew@utrccm.res.utc.com (Brian Wake) Subject: survey To: shapiro@Think.COM X-Envelope-To: shapiro@think.COM None of the items are important to me at this time. brian wake ----------------------------------------------------------------------------- Date: Thu, 7 May 92 16:47:56 -0400 From: tae@utrccm.res.utc.com (Alan Egolf) #1 Very limited value, almost nil. #2 I don't personally do this, and I don't like code which is written this way. I believe it is a drawback to days when memory was very limited. However, I can see some benefits for some problems. As such, I see low need for this feature. I have no current opinion on the second part of this question. #3 I have found this benefical in some cases. For instance common/data/ xyz(100,3) in subroutine a and common/data/ x(100),y(100),z(100) in subroutine b for programing convenience I would rate this as useful, with moderate to low need. Alan ------------------------------------------------------------------ From: Richard Shapiro Issue #1: Character data. Not important Issue #2: Sequence association Important, but not the default Issue #3: Storage association Not important, and not the default From @ecs.southampton.ac.uk,@camra.ecs.soton.ac.uk:jhm@ecs.southampton.ac.uk Thu Jun 4 11:32:03 1992 Received: from sun2.nsfnet-relay.ac.uk by cs.rice.edu (AA11848); Thu, 4 Jun 92 11:32:03 CDT Via: ecs.southampton.ac.uk; Thu, 4 Jun 1992 17:28:33 +0100 Via: camra.ecs.soton.ac.uk; Thu, 4 Jun 92 17:24:47 BST From: John Merlin Received: from bacchus.ecs.soton.ac.uk by camra.ecs.soton.ac.uk; Thu, 4 Jun 92 17:29:21 BST Date: Thu, 4 Jun 92 17:27:08 BST Message-Id: <280.9206041627@bacchus.ecs.soton.ac.uk> To: loveman@ftn90.enet.dec.com Subject: Re: Subset High Performance Fortran Cc: hpff-f90@cs.rice.edu I agree entirely with your lists of F90 features in and out of Subset HPF, except for one exceedingly minor quibble -- why is 'free source form input' *not* in Subset HPF, while most of its features (such as '!' comments, long names, etc) are included? However, this is such a trivial point that I don't really mind if you completely ignore it! John Merlin From @ecs.southampton.ac.uk,@camra.ecs.soton.ac.uk:jhm@ecs.southampton.ac.uk Thu Jun 4 12:50:52 1992 Received: from sun2.nsfnet-relay.ac.uk by cs.rice.edu (AA13530); Thu, 4 Jun 92 12:50:52 CDT Via: ecs.southampton.ac.uk; Thu, 4 Jun 1992 18:49:38 +0100 Via: camra.ecs.soton.ac.uk; Thu, 4 Jun 92 18:46:00 BST From: John Merlin Received: from bacchus.ecs.soton.ac.uk by camra.ecs.soton.ac.uk; Thu, 4 Jun 92 18:50:29 BST Date: Thu, 4 Jun 92 18:48:16 BST Message-Id: <335.9206041748@bacchus.ecs.soton.ac.uk> To: shapiro@think.com Subject: Re: Survey results concerning some F90 issues. Cc: hpff-f90@cs.rice.edu > I sent out a brief survey to Fortran users at both United Technologies Research > Center and Thinking Machines. The survey is below: > > ...stuff omitted... > Issue #2: Sequence association > > 5 would like it, 2 don't care. > Of the responders, 3 think the default should be no sequence > associated, 1 thinks the default should be sequence associated. I'd like to take issue with "Issue #2: Sequence association". In F77 one often *had* to resort to this (e.g. passing an array element as the actual argument corresponding to a dummy array, or reshaping an array parameter across a procedure boundary, or using assumed size arrays) -- there was no other (simple) way of achieving the desired effect. Better and more general ways of achieving these effects are made available by the array syntax of F90, viz. by using array sections as actual arguments, and using the RESHAPE intrinsic and assumed shape dummy arrays. Since it's proposed to include these features in Subset HPF, users can readily modify their codes to avoid these undesirable (and deprecated) aspects of sequence association. There's another important point -- F90 actually *forbids* shape disagreement between actual and dummy arguments if the procedure interface is specified in an INTERFACE block. I believe (and hope) that HPF may require the use of interface blocks in at least some circumstances when actual and or dummy arguments are distributed, so one won't be allowed to use these sequence association features according to F90. I wonder how many of your respondants who said 'yes' were fully aware of these issues? Therefore, I don't think one should beat one's head trying to support sequence association in a model where its basic assumptions clearly don't apply, namely for distributed data in HP Fortran -- particularly as simple and recommeded alternatives exist. As you mention, CM Fortran users live without it, presumably withuout too much pain. (Of course, there's no reason to disallow sequence association for non-distributed data.) Best regards, John Merlin ----------------------------------------------------------------------- John H. Merlin email: jhm@uk.ac.soton.ecs Dept. of Electronics and Computer Science, tel: +44 703 593368 University of Southampton, fax: +44 703 593045 Southampton S09 5NH, U.K. From zosel@phoenix.ocf.llnl.gov Thu Jun 4 20:04:32 1992 Received: from rice.edu ([128.42.5.1]) by cs.rice.edu (AA01192); Thu, 4 Jun 92 20:04:32 CDT Received: from phoenix.ocf.llnl.gov by rice.edu (AA27307); Thu, 4 Jun 92 20:03:46 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA04067; Thu, 4 Jun 92 18:04:43 -0700 Date: Thu, 4 Jun 92 18:04:43 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9206050104.AA04067@phoenix.ocf.llnl.gov> To: hpff-f90@rice.edu Subject: another survey answers FYI This Query about common blocks was sent to the users of the BBN TC2000 at LLNL. ------- Date: Fri, 29 May 92 12:24:44 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) To: users@mpci.llnl.gov Subject: hpf query to users interested in HPF - request for feedback: Mary Zosel would like opinions about the following question ... send any comments to zosel@llnl.gov -mz- ........ The High Performance Fortran Forum (HPFF) is defining a set of directives for use to describe how a user would like important arrays distributed across a machine with a physically distributed memory for massively parallel machines. There are, for example, directives for specification of BLOCK vs CYCLIC distributions and directives to specify how arrays should be aligned with respect to each other. An obvious question arise, when considering a port of existing Fortran codes - what do you do about F77 storage association problems? These are places where the code uses COMMON with different sizes or shapes of data in different subroutines - and / or uses EQUIVALENCE with arrays in COMMON - especially EQUIVALENCE which overlaps array boundaries. The HPFF committee looking at this issue has currently taken a very conservative approach: -------- Individual arrays in common blocks can be distributed ONLY if there are no EQUIVALENCE statements associated with any variable in the common block and every instance of the common block contains the same number of variables of the same sizes. -------- The argument FOR this conservative restriction is that the rule is simple to understand and to implement. In moving to parallel machines, there will be some level of re-write happening anyway - the programmers can separate out the important arrays into "clean" common blocks. There is another proposal which would allow the user to distribute an entire storage-associated COMMON block (not array by array). In cases where individual arrays can't be distributed, the block can be distributed instead. The argument AGAINST this conservative restriction says --- there are useful cases where equivalence can happen. Equivalence to one part of a common block should not kill distribution of an array in another part. Also, compilers are capable of sorting out what is the largest underlying equivalence array (maybe with some interprocedure work?). We should even allow distribution of arrays with equivalence under certain circumstances (which might be a bit complex to define exactly. WHAT DO YOU THINK? Simplicity and clean up the code or go for the most liberal definition possible, even if it is complex??? Mary needs feedback by Friday June 5th. ------------------ ----------------- HERE ARE ANSWERS Date: Fri, 29 May 92 12:35:56 PDT From: klind@tazdevil.llnl.gov (Kevin Robert Lind) Subject: Re: hpf query It seems to me that the most conservative approach is best, at least for now. The standard can be liberalized later if it should really prove to be necessary, but our level of experience and the need for correctness of programs and compilers I feel dictate a conservative approach until all of these issues get sorted out. Since most codes will need major rewrites anyway, it would be best to develop something definitely supportable to start with; a liberalized standard code would execute under the more conservative standard, but if it should turn out that the more conservative approach is required, you then have all sorts of half-done implementations, and codes that don't match the standard as implemented. SUMMARY: Let's do what we know we can do, and work toward the ideal model after a bit more experience. Regards, Kevin Lind ------------- Date: Fri, 29 May 92 12:39:38 PDT From: painter@hera.llnl.gov (Jeff Painter) Subject: Re: hpf query Remember that there are legitimate uses of EQUIVALENCE other than changing the shape of an array, merging arrays, etc.: e.g. do both fixed- and floating- point operations on the same array by equivalencing an integer name to a real name. The proposed rule you reported would ban even this. Jeffrey F. Painter painter1@llnl.gov L-316, Lawrence Livermore Laboratory painter@hera.llnl.gov Livermore CA 94551 USA 510-422-0675, FTS 532-0675 -------------- Date: Fri, 29 May 1992 12:51 PDT From: Ron Schmucker Subject: Re: hpf query I VOTE FOR SIMPLICITY AND CLEAN UP THE CODE! Ron Schmucker ------------- Subject: HPFF common Date: Fri, 29 May 92 13:35:14 -0700 From: lawver@arid.llnl.gov Mary, I am responding to the "question". I side with the conservative method. I think any other solution would "require" diagnostics from the compiler to explain how it resolve the complexity and what assumption it might have made in treating equivalence or dissimilar size common blocks. Those diagnostics will require as much effort to decipher as cleaning up the common blocks. Clean it up, make it say what you really mean. bryan ------------ Date: Fri, 29 May 92 13:39:53 PDT From: szoke@buster.llnl.gov (Hanna Szoke) Subject: Re: hpf query KISS - Keep It Simple and S.. don't remember what. The anticipated problems with a straightforward implementation sound like symptoms of ancient Fortran that is due for a rewrite in any case. Hanna Szoke. . ------------- Date: Fri, 29 May 92 22:08:02 PDT From: billc@bigbird.llnl.gov (Bill Crutchfield) Subject: Re: hpf query I think obscuring the parallel programming model just to preserve bad programming tricks of the past is a bad idea. Reliable parallel programming is difficult enough without introducing a rococco data distribution model where arrays can be a variety of different names and shapes, while still representing the same locations in memory. ----------- Date: Sun, 31 May 92 14:27:54 PDT From: bolstad@tazdevil.llnl.gov (John H. Bolstad) To: zosel@llnl.gov Subject: HPFF common Dear Mary, Regarding your "High Performance Fortran - Common Blocks" memo, I favor the "conservative" position. "Equivalence" is just a bad habit left over from Fortran II days, and since codes have to be rewritten anyway to go to massively parallel, this is a good time to get rid of this. Anyway, it just makes it more difficult to get correct code out of compilers. ... part of message deleted complaining about a compiler bug Finally, we have been rewriting several large codes for the BBN, and we have eliminated most common arrays, except possibly arrays whose length is independent of problem size. There are two reasons: One doesn't want to have to recompile for a change in problem size, and more importantly, if one has a fixed size problem, one doesn't want to have to recompile when the number of processors changes. So that means no problem-size dependent arrays in common anyway. For Fortran, the only (almost) portable memory management scheme seems to involve C subroutines that call malloc, perhaps covered up by calls to a macro processor like M4. So arrays in common (even without equivalence) are not so useful. John Bolstad bolstad@llnl.gov Date: Mon, 1 Jun 92 11:51:25 CDT From: alk@wt.msc.edu (Anthony L. Kimball) Yea! Good choice! //alk Date: Mon, 1 Jun 1992 11:22:58 -0600 From: Oliver McBryan > The argument AGAINST this conservative restriction says --- there are useful > cases where equivalence can happen. Equivalence to one part of a common bloc> should not kill distribution of an array in another part. Also, compilers ar > capable of sorting out what is the largest underlying equivalence array (mayb> with some interprocedure work?). We should even allow distribution of arrays > with equivalence under certain circumstances (which might be a bit complex to > define exactly. The problem that I see is that if HPF is to be of real use it should work for heterogeneous systems (e.g. a pseudo-machine consisting of 2 or more distinct computers tied together - e.g. a CRAY and a CM-5). However distinct systems may support different representations for integer or real variables and so distribution of an array to possibly a different archoitecture is possible only if one knows exactly which data types are stored in the array. Date: Mon, 1 Jun 92 15:08:47 GMT-0700 From: bill@cs.sandia.gov (William J. Camp) Art and Mary: Personally, while I used these constructs for years, and while I know that their removal from the large existing software base would NOT be trivial (in some cases the effort incurred might not be justifiable), I still think that they should be eliminated from any parallel version of fortran. They are not needed and do much to reduce flexibility, portability and reusability in fortran programs. On the other hand, our applications programmers seem to be moving to C++ for these issues and for developing parallel code. (So, maybe my comments are irrelevant.) The data parallel class of languages don't look to us like they will support true MIMD programming effectively for some time to come. Bill Camp, MPCRL at Sandia Date: Mon, 1 Jun 92 15:45:30 -0700 From: dcarbon@nas.nasa.gov (Duane F. Carbon) Dave DiNucci, a former LLNL employee (who apparently still gets email from your site), now works for us at NASA Ames Research Center's Numerical Aerodynamic Simulation (NAS) Facility. We are NASA's main computational center supporting advanced research in Computational Fluid Dynamics (CFD). We have taken the liberty to pass around to our CFD researchers a copy of your survey on HPF and COMMON/EQUIVALENCE statements which Dave gave us. I hope that you don't mind too much. I have appended below the first response from one of our scientists. Others may be forthcoming. Good luck, Duane Carbon Leader, Parallel Tools Group NAS Systems Development Branch ============================================================================ >Date: Mon, 1 Jun 92 14:20:57 -0700 >From: tedwards (Dr. Thomas A. Edwards) > >Duane - > >If you think this is the kind of feedback Mary wants, please forward it to her: > >Large-scale 3D CFD code development has moved away from EQUIVALENCE statements >and common blocks that are different throughout the code. There are a few >reasons for this. First, using these constructs can lead to undetected bugs. >Once a researcher has been bitten by one (at the cost of a week or more of >debugging), he tends to avoid using them again. Second, we are striving toward >machine-independent code, and the interpretation of these statements seems to >vary using different architectures, operating systems and compilers. Finally, >the ease of coding using "include" statements has led most of our researchers >to set up master common block files that are simply copied into the code at >compile time. This results in identical common blocks in all routines where >they are referenced. > >That's my two cents. > >Tom > >P.S. I presume you forwarded your mail to Lasinski's group as well? I'm >sending it on to two other people in my branch: Kalpana Chawla and Stuart >Rogers, oh and Scott Thomas and Steve Ryan as well. > Date: Tue, 2 Jun 92 08:24:00 PDT From: christon@ocfmail.ocf.llnl.gov (Mark Christon) Mary, It sounds like a lot of the issues that you are discussing regarding the distribution of arrays and common blocks came out of ParaDyn. My thinking on this issue is that ultimately, the more complex case of distributing common blocks would be nice, but it will be a while before anyone can really understand this well enough to exploit it in a "multi-platform" sense. While distributing common blocks array-by-array is seems to me to be a workable situation for now, the issue of partitioning arrays in subroutine calls is still not being addressed. This seems to be a far bigger issue in porting dusty decks which make use of the antiquated memory management strategy of extending blank common (ala CRAY memory management) for the short run. In the same vein, a common memory management interface would be nice, especially in light of what TMC has done with their CM_allocate/deallocate constructs which forces the user to perform additional work to keep track of array extents. Thanks, Mark Date: Wed, 3 Jun 92 17:53:48 PDT From: hoover@juno.llnl.gov ( Carol Hoover ) This is a response to your feedback request for the HPF meeting. Tony De Groot, Robert Whirley, and I discussed the problems we are faced with installing DYNA on the CM-5. After some deliberation, we decided we are strongly in favor of what you call the "liberal" approach. DYNA and the mpci report I sent you is an example of the tremendous amount of coding changes necessary to get Fortran standard data structures SIMPLY MOVED to a distributed memory machine. There is plenty of additional work necessary to implement efficient parallel syntax. This work to rewrite data structures which conform to Fortran standards to run on parallel machines is not productive effort for the scientist. The reasonable and productive work for a scientist is numerical algorithm research and modification for parallel systems. The technical argument we use to suggest retaining the Fortran 77/90 storage flexability and syntax in its present form for distributed memory machines is the following: Regardless of how you define the shapes and sizes of arrays in the usage of a COMMON block throughout the subprocedures as long as you know the first word address, the address calculation for any usage of arrays in a subprogram can be mapped into offsets from the fwa and this is done in the first stage of compilation. More specifically, the compiler address generation is equivalent to a one-dimensional array independen of what syntax the user has provided to point to a particular address or sub-block. The mapping of this linear array to processors and their local memories can be prescribed in whatever way the seems most appropriate for the architecture. But keep in mind, the user has specified a linear address mapping that is always unambiguous, both in his syntactical use as well as what he expects the compiler to do. The generation of array descriptors and the scheme for allocating the arrays to the physical processors is completely arbitrary and can be defined by the software and hardware specialists for any particular machine. We understand that implementation is not a trivial task for compiler developers. On the other and, the mission of computer scientists is to make computers useable for researchers (or end-users in other fields). Software developers have made a very convincing argument for several years that hardware-related issues requiring software changes be made ONCE in the system software rather than thousands of times in user-level software. The idea that can be communicated to computer manufacturers along this line is that the more useable they can make their product, the more researchers they will find wanting to hurry up and use their product. It would be extremely valuable for us if you, as a language specialist, could give the above ideas some thought and articulate it to the compiler specialists. I would be happy to spend some time discussing in more detail why I think the solid mechanics programs are not unique but rather representative of production codes. Let us know the results and we can discuss the issues more at the next ParaDyn meeting. Date: Thu, 4 Jun 92 16:54:06 -0700 From: dnielsen@mpci.llnl.gov (Dale Nielsen) Mary, I vote for the conservative restriction. Dale From loveman@ftn90.enet.dec.com Fri Jun 5 09:45:39 1992 Received: from enet-gw.pa.dec.com by cs.rice.edu (AA10184); Fri, 5 Jun 92 09:45:39 CDT Received: by enet-gw.pa.dec.com; id AA14589; Fri, 5 Jun 92 07:45:36 -0700 Message-Id: <9206051445.AA14589@enet-gw.pa.dec.com> Received: from ftn90.enet; by decwrl.enet; Fri, 5 Jun 92 07:45:37 PDT Date: Fri, 5 Jun 92 07:45:37 PDT From: David Loveman To: no@ftn90.enet.dec.com (to:), resent-to:@enet-gw.pa.dec.com, or@ftn90.enet.dec.com (apparently-to: field found) Cc: loveman@ftn90.enet.dec.com, hpff-f90@cs.rice.edu Apparently-To: hpff-f90@cs.rice.edu Subject: Re: Subset High Performance Fortran Thank you for your comments on Subset High Performance Fortran: >I agree entirely with your lists of F90 features in and out of >Subset HPF, except for one exceedingly minor quibble -- why is >'free source form input' *not* in Subset HPF, while most of its >features (such as '!' comments, long names, etc) are included? >However, this is such a trivial point that I don't really mind >if you completely ignore it! I included features that I felt were either critical, or important and not too hard to implement. My feeling is that free source form is important, yet not trivial to implement. (I know it's just lexing but . . .) I certainly would not fight including free source form in the subset - I write all my examples in it, and our next release of compilers will support it - but I can't argue that it should be required. If someone else wants to argue it case, i will vote "yes." -David From @ecs.southampton.ac.uk,@camra.ecs.soton.ac.uk:jhm@ecs.southampton.ac.uk Fri Jun 5 10:38:30 1992 Received: from sun2.nsfnet-relay.ac.uk by cs.rice.edu (AA12771); Fri, 5 Jun 92 10:38:30 CDT Via: ecs.southampton.ac.uk; Fri, 5 Jun 1992 16:37:49 +0100 Via: camra.ecs.soton.ac.uk; Fri, 5 Jun 92 16:33:51 BST From: John Merlin Received: from bacchus.ecs.soton.ac.uk by camra.ecs.soton.ac.uk; Fri, 5 Jun 92 16:38:27 BST Date: Fri, 5 Jun 92 16:36:13 BST Message-Id: <638.9206051536@bacchus.ecs.soton.ac.uk> To: loveman@ftn90.enet.dec.com Subject: Re: Subset High Performance Fortran Cc: hpff-f90@cs.rice.edu > I included features that I felt were either critical, or important > and not too hard to implement. My feeling is that free source form > is important, yet not trivial to implement. (I know it's just > lexing but . . .) I certainly would not fight including free > source form in the subset - I write all my examples in it, and > our next release of compilers will support it - but I can't argue > that it should be required. > > If someone else wants to argue it case, i will vote "yes." > > -David I entirely agree with your view. I like it, but it's not crucial to the purpose of HPF and so should probably be excluded from Subset HPF simply on those grounds. In fact, the lexical improvements you've included in Subset HPF correspond to the upgraded version of 'fixed source form' in F90 (except for omitting the ';' statement separator), which seems fine. John Merlin. From highnam@slcs.slb.com Fri Jun 5 16:44:29 1992 Received: from SLCS.SLB.COM by cs.rice.edu (AA04123); Fri, 5 Jun 92 16:44:29 CDT From: highnam@slcs.slb.com Received: from speedy.SLCS.SLB.COM by SLCS.SLB.COM (4.1/SLCS Mailhost 3.13) id AA06940; Fri, 5 Jun 92 16:44:00 CDT Received: by speedy.SLCS.SLB.COM (4.1/SLCS Subsidiary 1.10) id AA01100; Fri, 5 Jun 92 16:44:00 CDT Date: Fri, 5 Jun 92 16:44:00 CDT Message-Id: <9206052144.AA01100.highnam@speedy.SLCS.SLB.COM> To: hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu Subject: Sequence and Storage Association from Matthijs van Waveren (Delft) ( Matthijs served on the F90 committee. He has ``had trouble'' getting onto the HPFF mailing lists, so I am posting this msg for him. Our internal user group (spread over four countries) has been discussing HPF issues. Peter ) From: matthijs.van.waveren@gedsu1.SINet.SLB.COM (Matthijs van Waveren) To: highnam@gedsu1.SINet.SLB.COM Subject: Sequence and Storage Association Date: Fri, 5 Jun 92 16:09:17 CDT The following comments can be made on whether SSA semantics should be preserved in HPF. A similar discussion has previously taken place in the Fortran 90 committee. It is recognized that use of SSA will lead to saving of storage. However, from a software development point of view, it is a dangerous concept. To keep HPF compatible with the older Fortran standards, it will be necessary to keep SSA for Fortran 77 type COMMON blocks. In Fortran 90, alternatives for COMMON blocks are available. Since Fortran 90 will be the baseline for HPF, a new proposal should be considered: Support COMMON blocks with full Fortran 77 SSA and distribute it as a block. Use the MODULE concept of Fortran 90 to make distributed arrays commonly available to different subprograms. This would make the creation of a new type COMMON unnecessary. The following example of the use of modules for this purpose can be found in the book of Metcalf and Reid: "Fortran 90 Explained", Chapter 5. PROGRAM GAME CALL SHUFFLE CALL DEAL CALL PLAY CALL DISPLAY END PROGRAM GAME The following MODULE might hold the state of the play of the game: MODULE STATE INTEGER, DIMENSION(52) :: CARDS END MODULE STATE The statement USE STATE appears at the beginning of the subprograms SHUFFLE, DEAL, PLAY and DISPLAY to make the state of the play accessible to those subprograms. Cheers, - -- -------------------------------------------------------- | Matthijs van Waveren | | Schlumberger/GECO PRAKLA R&D and ISO/WG5 | | P.O. Box 148, 2600 AC Delft, the Netherlands | | Tel=> Direct: (+31) 15 682106 Oper: (+31) 15 682100 | -------------------------------------------------------- From @ecs.southampton.ac.uk,@camra.ecs.soton.ac.uk:jhm@ecs.southampton.ac.uk Mon Jun 8 09:07:38 1992 Received: from sun2.nsfnet-relay.ac.uk by cs.rice.edu (AA01171); Mon, 8 Jun 92 09:07:38 CDT Via: ecs.southampton.ac.uk; Mon, 8 Jun 1992 13:03:03 +0100 Via: camra.ecs.soton.ac.uk; Mon, 8 Jun 92 12:59:23 BST From: John Merlin Received: from bacchus.ecs.soton.ac.uk by camra.ecs.soton.ac.uk; Mon, 8 Jun 92 13:04:02 BST Date: Mon, 8 Jun 92 13:01:48 BST Message-Id: <1009.9206081201@bacchus.ecs.soton.ac.uk> To: hpff-f90@cs.rice.edu Subject: Erratum in previous message re. sequence association Whoops! In I asserted: > > There's another important point -- F90 actually *forbids* > shape disagreement between actual and dummy arguments if the > procedure interface is specified in an INTERFACE block. As John Reid pointed-out to me, this assertion is wrong. It seems that it was true in Fortran 8x but was changed in the final draft of Fortran 90. Therefore I withdraw this particular 'important point' and apologise for the misinformation. Regards, John Merlin From frese@sc.zib-berlin.de Thu Jun 11 04:42:53 1992 Received: from serv02.ZIB-Berlin.DE by cs.rice.edu (AA17557); Thu, 11 Jun 92 04:42:53 CDT Received: from ave.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA27436; Thu, 11 Jun 92 11:41:05 +0200 Received: from avus.ZIB-Berlin.DE by ave.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA01126; Thu, 11 Jun 92 11:41:02 +0200 Date: Thu, 11 Jun 92 11:41:02 +0200 From: frese@sc.zib-berlin.de (Hans-Hermann Frese) Message-Id: <9206110941.AA01126@sc.zib-berlin.dbp.de> To: hpff-f90@cs.rice.edu Subject: NAGUA Workshop on Fortran 90 NAGUA NAGUA Workshop on Fortran 90 The future of Fortran here today Monday 22 June 1992 Hannover, Germany An Invitation -------------------------------------------------------------- The Workshop is to be held on Monday 22 June 1992 at the Interconti Hotel in Hannover Agenda ------ 10.00 Opening remarks Thomas Haarmann, NAGUA 10.05 "Fortran 90 through the eyes of a Fortran 77 Programmer" Wilhelm Gehrke, RRZN, University of Hannover 11.20 Tea/Coffee 11.45 "How NAG and its users will benefit from Fortran 90" John Reid, Rutherford Appleton Laboratory 12.45 Lunch 14.00 "Fortran 90 Compiler and Tools" Malcolm Cohen, NAG Limited 14.45 "Designing a Fortran 90 Numerical Library" Jeremy Du Croz, NAG Limited 15.30 Tea/Coffee 16.00 Application session 17.00 End of Workshop Wilhelm Gehrke is the author of the "Fortran 90 Referenz Handbuch". John Reid, together with Mike Metcalf, is the author of the book "Fortran 90 Explained". Malcolm Cohen is the author of the NAGWare f90 compiler. Jeremy Du Croz is co-ordinator of the development of the NAG Fortran Library at NAG Ltd. ----------------------------------------------------------------- Booking Form ------------ Please complete the following and return to the NAGUA Administrator or fax on +44 865 310139. Thank you for your invitation to attend the NAGUA Fortran 90 Workshop I am able to attend __ I am unable to attend __ I am interested in receiving information about future information about NAGUA and NAG products and services Name .......................... Title ................... Organisation ............................................... Address .................................................... .................................................... .................................................... Country ....................... Post Code ............... Tel No ........................ Fax No .................. ------------------------------------------------------------- Fees ---- The fee for the one-day Workshop will be DM 500 I am entitled to the DM 160 educational discount - DM I am entitled to the DM 180 NAGUA member discount - DM ------------------------------------------------------------ The total amount to be paid is DM ------------------------------------------------------------ Method of Payment ----------------- Please find cheque for the total sum enclosed __ I have arranged to pay by Direct Bank Transfer __ ------------------------------------------------------------ Fees The fee to attend the workshop is DM 500 and includes lunch and tea/coffe. There is a DM 160 educational discount and a DM 180 discount for NAGUA members. Please tick the relvant boxes on the booking form if you are entitled to one or both of these discounts. If you are paying by direct bank transfer from outside Germany then an additional fee of DM 15 is required to cover bank charges. Method of Payment There are two different methodes of payment available: 1. Pay the full amount by cheque (payable to Thomas Haarmann, NAGUA 91 Workshop) and return the cheque and book form to: NAGUA Administrator PO Box 426 Oxford United Kingdom OX2 8SD 2. Pay the total amount by Direct Bank Transfer to Bank: Deutsche Bank Osnabrueck Account No: 0171066 03 (BLZ 265 700 90) Account Name: Thomas Haarmann, NAGUA 92 Workshop Further Information Payments are also possible in Sterling. Please contact the NAGUA Administrator for further details. Provisional bookings will be accepted by telephone: +44 865 311102 or by fax: +44 865 310139. The closing date for apllications is wednesday 17 June 1992 and no refunds can be guaranteed after this date. Confirmation of your booking and details of local arrangements etc will be sent out on receipt of your booking form. Details of overnight accommodation in local hotels are available on request. NAGUA Administrator, PO Box 426, OXFORD, United Kingdom OX2 8SD From chk@erato.cs.rice.edu Thu Jun 11 16:31:08 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA04394); Thu, 11 Jun 92 16:31:08 CDT Received: from localhost.cs.rice.edu by erato.cs.rice.edu (AA00724); Thu, 11 Jun 92 16:31:06 CDT Message-Id: <9206112131.AA00724@erato.cs.rice.edu> To: hpff-f90@erato.cs.rice.edu Cc: chk@erato.cs.rice.edu, hanson@imsl.com Word-Of-The-Day: comity : (n) friendly social atmosphere; social harmony Subject: Recently received Date: Thu, 11 Jun 92 16:31:04 -0500 From: chk@erato.cs.rice.edu This arrived (in hardcopy format) during the HPFF meeting. I offer it as fodder for the F90 group discussion. Typos are mine. Chuck hanson@imsl.com 713-297-1061 June 6, 1992 Dear Charles, Here is a report that I mentioned to you. In the Introcudtion, parge 1, there is a list of the critical language elements that will allow us to write viable mathematical software. I think that any proposal by the HPF that skirts the full standard, in any way, is asking for resistance by the user community. I suggest you should implement the entire standard in your binding. Perhaps leaving it up to the individual hardware vendors about small details. That way the software vendors can move functioning code to new machines with a minimum of changes. Sincerely, Richard J. Hanson Senior Mathematical Designer Technical Staff ------------------------------------------------------------------------------- [the report is 21 pages long - here's the first page] A Design of High-Performance Fortran 90 Libraries by Richard J. Hanson, IMSL, Inc. IMSL Technical Report Series No. 9201 1. Introduction and Rationale The aspect of scientific computation that emplowys parallel computing resources is a maturing subject that requires some retraining of programmers who are principally familiar with sequential compution. IMSL, Inc. wants to help programmers by providing mathematical software products of the highest quality. Practitioners and programmers tolerate the complications associated with exploiting parallel computing resources because of requirements for efficiency in application software. It is an elementary observation that to complete disjoint tasks, parallel activity is going to be efficient. This fits well with common life experience: share the work to get it done faster. What may not ahve a counterpart in life experience is the control, communication and synchronization associated with parllel computing activities. This report outlines methods for the entire design and support cycle leading to a transportable subroutien and interface library. The resulting product can be used as the basis for massively parallel or mult8i-tasking, shared memory computations. The implementations are specific to the Fortran 90 language. The model for the livrary defined in the following sections makes no assumption about the operating system that is not supported in the language. The critical new language elements, allocatable arrays, automatic arrays, optional arguments, derived types, and internal subroutines, recursive subroutines, and modules, provide the means to design high-quality library codes that do double duty: they can function in a serial or parallel code. Our experiments with the language are based on the compiler from NAG (1991). The model of massively parallel or multi-tasking computing the we believe will be effective consists of algorithsm written in Fortran 90 together with critical implementation details. Several key points that contribute to the portability of this software are listed below. Section 3, "Technical Differences", on page 4 and Section 4, "Option Arrays", on page 6 discuss each of these matters separaately. Section 6, "sample Routines", on page 7 gives examples of using a linear solver and a one-dimensional function minimizing routine. * Copies of private vraiables can be saved in the called program unit whenever the routine is to be reentered in a predictable state. * COMMON is not used in any HL Series code * No output is attempted; a derived type is optionally used for the logical pointers to error messages that are delivered by a utility. * STOP is not executed. * Optional arguments, including error and option arrays, specified as derived dta types, are used to shorten argument lists and communicate data for output. From highnam@slcs.slb.com Fri Jun 12 18:18:15 1992 Received: from SLCS.SLB.COM by cs.rice.edu (AA25015); Fri, 12 Jun 92 18:18:15 CDT From: highnam@slcs.slb.com Received: from speedy.SLCS.SLB.COM by SLCS.SLB.COM (4.1/SLCS Mailhost 3.13) id AA06198; Fri, 12 Jun 92 18:18:04 CDT Received: by speedy.SLCS.SLB.COM (4.1/SLCS Subsidiary 1.10) id AA00279; Fri, 12 Jun 92 18:18:05 CDT Date: Fri, 12 Jun 92 18:18:05 CDT Message-Id: <9206122318.AA00279.highnam@speedy.SLCS.SLB.COM> To: hpff-f90@cs.rice.edu, hpff-distribution@cs.rice.edu Subject: Proposal to add declarative MODULEs to HPF During the June HPFF mtg the issue of local versus globally available names arose in several ways: a. Sequence and Storage Association (``SSA''). Group 1's proposal provided two forms of named COMMON. One form may only hold individually distributed objects. The other form is essentially identical to that of F77: all objects within it cannot be individually distributed, but full SSA applies to the entire block. A modification of this proposal by Andy Meltzer to permit the SSA block to be distributed as a single entity was accepted. Ken Kennedy entered an alternative proposal in which there is only one form of named COMMON. This COMMON can intermix objects that are individually distributed with ``sequential'' objects on which full SSA is available. The user is required to ensure that the intermixing is consistent across subprograms. In particular, that sequential objects and individually distributed objects do not ``overlap'' across subprogram units. b. The status of the names of TEMPLATEs and of PROCESSOR arrangements is not well defined. They are declared within a subprogram and exist only within that subprogram. They cannot be passed as arguments and cannot be placed in COMMON. Thus, we have language entities with similar usage to F90 derived types that only exist within a single subprogram (not just their names, but the actual entity!). Matthijs van Waveren has pointed out that the F90 MODULE is the appropriate solution for these problems. A MODULE provides a mechanism to make object names globally available without the semantic baggage of a COMMON block. Furthermore, because F90 derived types may appear in a MODULE, this is the right way to make TEMPLATE and PROCESSOR arrangement names globally available. However, vendors in the HPFF meetings have indicated that the F90 MODULE represents substantial implementation overhead. Thus, in keeping with both our commitment to F90 as the base language, and our goal of timely HPF definition and availability, I propose that we *require* a specification-part only form of the F90 MODULE. (See below for details.) Vendors are, of course, free to implement other MODULE functionality. ********************************************************************** Proposal: Require F90 MODULE specification part and renaming facility. All COMMON blocks should have full F77 SSA, and be distributable as a single entity. ********************************************************************** Module definition: ----------------- MODULE module-name specification statements END [ MODULE [ module-name ] ] Where ``specification statements'' are those of F90 augmented with those of HPF. Example: MODULE named_common_1 INTEGER , PARAMETER :: N = 1024 CHPF TEMPLATE grid_points ( N , N ) REAL , ARRAY( N , N ), ALIGN WITH grid_points :: bug_count_per_grid_point END MODULE named_common_1 C The names available from this module are: N , grid_points , bug_count_per_grid_point Module use: ---------- USE module-name [, rename-list ] This statement is placed ahead of the specification statements within program units that employ a module. The rename-list capability permits an entity within the module to be identified by another name within the subprogram unit in which the USE statement appears. Thus, the renaming ``facility'' of COMMON can be mimicked. Example: SUBROUTINE report_them_all USE named_common_1 , N_GRID_POINTS => N bug_count_per_grid_point = bug_count_per_grid_point + 1 END SUBROUTINE report_them_all For discussion: . How much additional work will this require of vendors ? Is this outweighed by simplification elsewhere ? . Entities within modules can be declared PUBLIC or PRIVATE. (The default can be set at the head of the module.) Should this functionality also be required ? I'm inclined to say yes, because then TEMPLATEs and PROCESSOR arrangement names can be hidden. Peter From zosel@phoenix.ocf.llnl.gov Mon Jun 22 11:08:00 1992 Received: from rice.edu ([128.42.5.1]) by cs.rice.edu (AA09393); Mon, 22 Jun 92 11:08:00 CDT Received: from phoenix.ocf.llnl.gov by rice.edu (AA29337); Mon, 22 Jun 92 11:07:16 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA12931; Mon, 22 Jun 92 09:08:00 -0700 Date: Mon, 22 Jun 92 09:08:00 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9206221608.AA12931@phoenix.ocf.llnl.gov> To: hpff-f90@rice.edu Subject: washington meeting? Group 1 The schedule that Ann sent out does not match the notes I took at the last meeting about the schedule. I have sent a query to Chuck for clarification. I will not arrive until late afternoon Wednesday. If there is no ICS BOF, we could schedule a Wed. evening subgroup meeting - but a BOF would take precedence if it is arranged. I'm hoping there will be time on Thursday am for some subgroup discussions. For the meeting, we expect to have the proposal from Ken to compare with the Schreiber/Swift proposal. One of these should be adopted at the meeting. We also should consider the possibility of procedureless modules to see if this is a help for the template scope problems. I also note that we were rather impulsive in including interface blocks and array sections without any restrictions in the proposal for the array sublanguage. I think what we intended for the interface blocks was just the subroutine prototypes --- not the operator definitions, etc. Also for array sections, especially when crossing subroutine boundaries, we might want to consider some limitations - these sections can get very creative - and I note that group 2 is having some interesting discussions about even the "simple" regular sections. -mary- From zosel@phoenix.ocf.llnl.gov Thu Jun 25 10:42:22 1992 Received: from rice.edu ([128.42.5.1]) by cs.rice.edu (AA03692); Thu, 25 Jun 92 10:42:22 CDT Received: from phoenix.ocf.llnl.gov by rice.edu (AA24640); Thu, 25 Jun 92 10:41:37 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA14033; Thu, 25 Jun 92 08:42:17 -0700 Date: Thu, 25 Jun 92 08:42:17 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9206251542.AA14033@phoenix.ocf.llnl.gov> To: hpff-f90@rice.edu Subject: "collateral standards" You might be interested in the following paragraph which is taken from a report that Jerrold Wagener sent out about a May X3/SPARC meeting. -mary- --- On collateral standards (e.g., POSIX, X3H5, HPF), SPARC is divided and has no clear directional advice. This is clearly an area for some imaginative lead- ership. The one point of agreement is that no new collateral standards should be written against Fortran 77; all should specify Fortran 90, with Fortran 77 subsets a possibility. From chk@erato.cs.rice.edu Fri Jun 26 08:45:48 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA01037); Fri, 26 Jun 92 08:45:48 CDT Received: from localhost.cs.rice.edu by erato.cs.rice.edu (AA09382); Fri, 26 Jun 92 08:45:47 CDT Message-Id: <9206261345.AA09382@erato.cs.rice.edu> To: hpff-f90@erato.cs.rice.edu Word-Of-The-Day: prosaic : (adj) 1. characteristic of prose; factual 2. having a dull, flat, or unimaginative quality Subject: Resent from Mary Date: Fri, 26 Jun 92 08:45:45 -0500 From: chk@erato.cs.rice.edu For reasons still under investigation, this message doesn't seem to have gotten out. Apologies for the repeat if it did get to some of you... Date: Thu, 25 Jun 92 08:42:17 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9206251542.AA14033@phoenix.ocf.llnl.gov> To: hpff-f90@rice.edu Subject: "collateral standards" You might be interested in the following paragraph which is taken from a report that Jerrold Wagener sent out about a May X3/SPARC meeting. -mary- --- On collateral standards (e.g., POSIX, X3H5, HPF), SPARC is divided and has no clear directional advice. This is clearly an area for some imaginative lead- ership. The one point of agreement is that no new collateral standards should be written against Fortran 77; all should specify Fortran 90, with Fortran 77 subsets a possibility. From highnam@slcs.slb.com Fri Jun 26 11:25:27 1992 Received: from SLCS.SLB.COM by cs.rice.edu (AA06809); Fri, 26 Jun 92 11:25:27 CDT From: highnam@slcs.slb.com Received: from speedy.SLCS.SLB.COM by SLCS.SLB.COM (4.1/SLCS Mailhost 3.13) id AA21857; Fri, 26 Jun 92 11:25:03 CDT Received: by speedy.SLCS.SLB.COM (4.1/SLCS Subsidiary 1.10) id AA06899; Fri, 26 Jun 92 11:25:02 CDT Date: Fri, 26 Jun 92 11:25:02 CDT Message-Id: <9206261625.AA06899.highnam@speedy.SLCS.SLB.COM> To: hpff-f90@cs.rice.edu Subject: HPF array constructors questions Can someone in the F90 subgroup, comment on the syntax and semantics of the proposed HPF array constructor and its usage ? E.g., Will the HPF array constructor syntax follow F90's "(/ /)" notation and implicit DO style ? iota = (/ (i,i=1,n) /) Or the more compact CMFortran: iota = [ 1:n ] E.g., Is this ok ? (n,k are runtime values): a_complex_vector * cmplx( (/ i,i=2,n,k /) ) a_complex_vector * cmplx( [ 2:n:k ] ) E.g., Is this ok ? (m,n are runtime values): FORALL( i=1:n ) fred(i,:) = (i-1)*m + (/ i,i=1,m /) FORALL( i=1:n ) fred(i,:) = (i-1)*m + [ 1:m ] E.g., Is this ok ? (m,n are runtime values): fred = RESHAPE( (/ i=1,m*n /) , (/ n,m /) ) fred = RESHAPE( [1:m*n] , [n,m] ) Just sanity checking. Thanks, Peter From @ricevm1.rice.edu:METCALF@crnvma.cern.ch Fri Jun 26 12:06:05 1992 Received: from ricevm1.rice.edu by cs.rice.edu (AA08046); Fri, 26 Jun 92 12:06:05 CDT Message-Id: <9206261706.AA08046@cs.rice.edu> Received: from RICEVM1.RICE.EDU by ricevm1.rice.edu (IBM VM SMTP V2R2) with BSMTP id 2491; Fri, 26 Jun 92 12:05:33 CDT Received: from CERNVM.cern.ch by RICEVM1.RICE.EDU (Mailer R2.08 R208004) with BSMTP id 3909; Fri, 26 Jun 92 12:05:31 CDT Received: from CERNVM.CERN.CH (METCALF) by CERNVM.cern.ch (Mailer R2.08) with BSMTP id 0172; Fri, 26 Jun 92 19:05:18 SET Date: Fri, 26 Jun 92 18:46:31 SET From: Michael Metcalf Subject: Queries To: hpff-f90@cs.rice.edu Coming, as I do, late into the discuusion, I would be grateful for a number of clarifications based on the document dated 1 June: 1) Has it been noticed that MVBITS appears both in the list of intrinsic functions (incorrectly) and in the list of intrinsic subroutines (correctly) that are f90 subset features? 2) Should the reference to assumed-size arrays that is in the list of features not in the f90 subset in fact be to assumed-shape arrays? 3) If interface blocks are to be allowed in the subset, the most convenient way to handle them is by adding them to a MODULE and USEing it. Similarly, the most convenient way to break some of the unwanted storage association properties of arrays in COMMON is to specify them instead in type specification statements placed in a MODULE and to propagate them throughout a program by USE statements. Is there thus not a good case for adding *limited* MODULE/USE functionality to the subset? Would that not make the task of the association WG easier? Can anyone enlighten me? With many thanks, Mike Metcalf From loveman@ftn90.enet.dec.com Tue Jun 30 11:19:37 1992 Received: from enet-gw.pa.dec.com by cs.rice.edu (AA23394); Tue, 30 Jun 92 11:19:37 CDT Received: by enet-gw.pa.dec.com; id AA04813; Tue, 30 Jun 92 09:19:31 -0700 Message-Id: <9206301619.AA04813@enet-gw.pa.dec.com> Received: from ftn90.enet; by decwrl.enet; Tue, 30 Jun 92 09:19:34 PDT Date: Tue, 30 Jun 92 09:19:34 PDT From: David Loveman To: highnam@slcs.slb.com Cc: hpff-f90@cs.rice.edu, loveman@ftn90.enet.dec.com Apparently-To: highnam@slcs.slb.com, hpff-f90@cs.rice.edu Subject: RESEND: Re: HPF array constructors questions My best guess answers to your questions: - ---------- E.g., Will the HPF array constructor syntax follow F90's "(/ /)" notation and implicit DO style ? iota = (/ (i,i=1,n) /) Or the more compact CMFortran: iota = [ 1:n ] - ---------- There is no "HPF array constructor," just the Fortran 90 array constructor. The "[ . . . ]" notation is from Fortran 8x and is not a part of Fortran 90, thus should be considered a non-standard extension. It is also supported by MasPar Fortran, DECmpp Parallel Fortran, and is planned to be in DEC Fortran 90. Array constructors that are initialization expressions can be initial values, as in integer, dimension(n) :: iota = (/ (i,i=1,n) /) - ---------- E.g., Is this ok ? (n,k are runtime values): a_complex_vector * cmplx( (/ i,i=2,n,k /) ) a_complex_vector * cmplx( [ 2:n:k ] ) - ---------- Array constructors can have runtime values. - ---------- E.g., Is this ok ? (m,n are runtime values): FORALL( i=1:n ) fred(i,:) = (i-1)*m + (/ i,i=1,m /) FORALL( i=1:n ) fred(i,:) = (i-1)*m + [ 1:m ] - ---------- The array constructor is syntactically incorrect, and should be (/ (i,i=1,m) /). When fixed up, it causes my compiler to die painfully (thanks for the test case) - ---------- E.g., Is this ok ? (m,n are runtime values): fred = RESHAPE( (/ i=1,m*n /) , (/ n,m /) ) fred = RESHAPE( [1:m*n] , [n,m] ) - ----------- Syntax error, array constructor should be (/ (i,i=1,m*n) /). Otherwise seems ok. From loveman@ftn90.enet.dec.com Tue Jun 30 11:49:10 1992 Received: from enet-gw.pa.dec.com by cs.rice.edu (AA24088); Tue, 30 Jun 92 11:49:10 CDT Received: by enet-gw.pa.dec.com; id AA07230; Tue, 30 Jun 92 09:49:04 -0700 Message-Id: <9206301649.AA07230@enet-gw.pa.dec.com> Received: from ftn90.enet; by decwrl.enet; Tue, 30 Jun 92 09:49:08 PDT Date: Tue, 30 Jun 92 09:49:08 PDT From: David Loveman To: highnam@slcs.slb.com Cc: hpff-f90@cs.rice.edu, loveman@ftn90.enet.dec.com Apparently-To: highnam@slcs.slb.com, hpff-f90@cs.rice.edu Subject: RESEND: Re: HPF array constructors questions My best guess answers to your questions: - - ---------- E.g., Will the HPF array constructor syntax follow F90's "(/ /)" notation and implicit DO style ? iota = (/ (i,i=1,n) /) Or the more compact CMFortran: iota = [ 1:n ] - - ---------- There is no "HPF array constructor," just the Fortran 90 array constructor. The "[ . . . ]" notation is from Fortran 8x and is not a part of Fortran 90, thus should be considered a non-standard extension. It is also supported by MasPar Fortran, DECmpp Parallel Fortran, and is planned to be in DEC Fortran 90. Array constructors that are initialization expressions can be initial values, as in integer, dimension(n) :: iota = (/ (i,i=1,n) /) - - ---------- E.g., Is this ok ? (n,k are runtime values): a_complex_vector * cmplx( (/ i,i=2,n,k /) ) a_complex_vector * cmplx( [ 2:n:k ] ) - - ---------- Array constructors can have runtime values. - - ---------- E.g., Is this ok ? (m,n are runtime values): FORALL( i=1:n ) fred(i,:) = (i-1)*m + (/ i,i=1,m /) FORALL( i=1:n ) fred(i,:) = (i-1)*m + [ 1:m ] - - ---------- The array constructor is syntactically incorrect, and should be (/ (i,i=1,m) /). When fixed up, it causes my compiler to die painfully (thanks for the test case) - - ---------- E.g., Is this ok ? (m,n are runtime values): fred = RESHAPE( (/ i=1,m*n /) , (/ n,m /) ) fred = RESHAPE( [1:m*n] , [n,m] ) - - ----------- Syntax error, array constructor should be (/ (i,i=1,m*n) /). Otherwise seems ok. From zrlp09@trc.amoco.com Wed Jul 8 09:51:16 1992 Received: from noc.msc.edu by cs.rice.edu (AA22415); Wed, 8 Jul 92 09:51:16 CDT Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA29997; Wed, 8 Jul 92 09:51:13 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA10595; Wed, 8 Jul 92 09:51:13 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA26603; Wed, 8 Jul 92 09:51:09 CDT Received: from backus.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA00376; Wed, 8 Jul 92 09:51:07 CDT Received: from localhost by backus.trc.amoco.com (4.1/SMI-4.1) id AA20886; Wed, 8 Jul 92 09:51:06 CDT Message-Id: <9207081451.AA20886@backus.trc.amoco.com> To: hpff-f90@cs.rice.edu Subject: test message - sorry for the intrusion Date: Wed, 08 Jul 92 09:51:06 -0500 From: "Rex Page" I've received no HPFF mail since June 30. Just checking to see if the reflector still works. Rex From schreibr@riacs.edu Tue Jul 14 19:25:18 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA18719); Tue, 14 Jul 92 19:25:18 CDT Received: from icarus.riacs.edu by erato.cs.rice.edu (AA15569); Tue, 14 Jul 92 19:25:12 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA09186; Tue, 14 Jul 92 17:25:11 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA03302; Tue, 14 Jul 92 17:23:54 PDT Message-Id: <9207150023.AA03302@thor.riacs.edu> Date: Tue, 14 Jul 92 17:23:54 PDT From: Rob Schreiber To: hpff-distribute@erato.cs.rice.edu Subject: Replication, etc. Cc: hpff-f90@erato.cs.rice.edu Topics: 1. Distributing COMMON is not necessary. 2. Replication belongs in distribute. 3. No sequential variables in alignments. 4. Wrapping twice is a bad idea. At the last meeting, we more or less agreed with Andy Meltzer to allow COMMON blocks to appear in directives. Our goal is to allow the user to distribute sequential COMMON as if it were a one-dimensional array. THe user might want to replicate the COMMON on all processors, for example. Ken Kennedy also argued successfully for a rule that breaks up a COMMON into the sequential aggregates created by EQUIVALENCE and the non-storage-associated variables not touched by EQUIVALENCE, allowing the latter to be distributed freely. Ken and I have drafted a proposal along those lines. This effort has revealed a few things that seem important to me. 1. We dont need to distribute COMMON blocks. We can get the same effect by distributing a local that is equivalenced in such a way that it "covers" the COMMON block. This is an big simplification. COMMON blocks may not occur in mapping directives, only variables, templates, and processor arrangements. 2. In the current draft on directives, replication is allowed in (RE)ALIGN but not in (RE)DISTRIBUTE directives. This is a mistake for two reasons. a. What if I want ONE COPY PER PROCESSOR? Replicating onto a template is a funny way to express this. b. Replicating a sequential part (or all of) a COMMON block CANNOT BE DONE using (RE)ALIGN because of (3) below. 3. We are proposing to have sequential variables, and to allow them to be used in some directives. If I ALIGN a sequential variable to a template, the effect will be to make the template sequential, too! This is *not* desirable. Thus, we should make the rule: Sequential variables may not occur in (RE)ALIGN(ABLE) directives. If one-dimensional, they may occur in (RE)DISTRIBUTE(ABLE) directives. And we should allow replication in the (RE)DISTRIBUTE directives by some appropriate syntax. 4. We also squeezed wraparound in alignment into the system. There is already wraparound in the CYCLIC(k) distributions. Now we can get double wraparound mappings like this: real X(24) template T(10) processors P(4) ALIGN X with T (wraps twice) DISTRIBUTE CYCLIC(2) ONTO X :: T (wraps again) Yields: Processor: 1 | 2 | 3 | 4 | | | | | | T Indices: 1 2 | 3 4 | 5 6 | 7 8 9 10 | | | | | | | | | X Indices: 1 2 | 3 4 | 5 6 | 7 8 9 10 | | | 11 12 | 13 14 | 15 16 | 17 18 19 20 | | | 21 22 | 23 24 | | **** DO WE WANT THIS? **** From halstead@crl.dec.com Fri Jul 17 15:11:06 1992 Received: from crl.dec.com by cs.rice.edu (AA20779); Fri, 17 Jul 92 15:11:06 CDT Received: by crl.dec.com; id AA23433; Fri, 17 Jul 92 16:10:58 -0400 Received: by easynet.crl.dec.com; id AA28542; Fri, 17 Jul 92 16:10:12 -0400 Message-Id: <9207172010.AA18155@seine.crl.dec.com> To: Rob Schreiber Cc: halstead@crl.dec.com, hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu In-Reply-To: your message of Tue, 14 Jul 92 17:23:54 PDT <9207150023.AA03302@thor.riacs.edu> Subject: re: Replication, etc. Date: Fri, 17 Jul 92 16:10:53 -0400 From: halstead@crl.dec.com X-Mts: smtp Date: Tue, 14 Jul 92 17:23:54 PDT From: Rob Schreiber 2. In the current draft on directives, replication is allowed in (RE)ALIGN but not in (RE)DISTRIBUTE directives. This is a mistake for two reasons. a. What if I want ONE COPY PER PROCESSOR? Replicating onto a template is a funny way to express this. Well, I think it was always the intention of replication specifications in (RE)ALIGN directives to yield only one copy per processor. The intuition is that you are saying in your (RE)ALIGN directive that you want a copy of the replicated datum available cheaply at each template point specified (presumably because you use the replicated datum in operations involving other data aligned to each of those template points). However, if the distribution in use maps all of the template points over which a datum is replicated onto the same processor, then in fact only one copy of the "replicated" datum will be allocated. And in the more general case, there will only be one copy of the replicated datum for each processor onto which one or more of those template points is mapped. This is the intended semantics of replicated alignments, and in my opinion it is the only useful one -- why you would ever want more than one replica of the same datum on the same processor is beyond me! If the current specifications don't make these intended semantics clear enough, maybe they need to be revised... b. Replicating a sequential part (or all of) a COMMON block CANNOT BE DONE using (RE)ALIGN because of (3) below. 3. We are proposing to have sequential variables, and to allow them to be used in some directives. If I ALIGN a sequential variable to a template, the effect will be to make the template sequential, too! This is *not* desirable. Just a quick question: what is a "sequential template" and why don't I want to have one? In other words, what am I allowed to do with other kinds of templates that I'm not allowed to do with sequential templates? I don't understand the answers to these questions, and without understanding them, I don't understand why it's undesirable to allow the kind of alignment that you propose to outlaw. Thus, we should make the rule: Sequential variables may not occur in (RE)ALIGN(ABLE) directives. If one-dimensional, they may occur in (RE)DISTRIBUTE(ABLE) directives. And we should allow replication in the (RE)DISTRIBUTE directives by some appropriate syntax. Well, this sounds like something that you'll have to work out in determining the rules for using "sequential" variables. But if you have to introduce another concept to handle this situation, there is probably more than one solution to the problem of "contaminating" templates by aligning sequential variables to them. The details will certainly depend on the goals you are trying to achieve, but instead of _distributing_ sequential variables directly onto the processors (and introducing the concept of replicated distributions) it might be just as simple to introduce the concept of an "anonymous" or "sequential" template that has the same size as the array of processors, to which your sequential variables are _aligned_ (making available the existing syntax for specifying replicated alignments). In any case, my argument is that if you introduce a concept of replicated distributions, you will only be doing it to deal with cases 2b and 3. I disagree that it's needed for your case 2a. 4. We also squeezed wraparound in alignment into the system. There is already wraparound in the CYCLIC(k) distributions. Now we can get double wraparound mappings like this: ... **** DO WE WANT THIS? **** Your example strikes me as the most cogent argument yet against wraparound in alignment directives. When there are truncation effects that leave more data elements (resp. template points) on some template points (resp. processors) than on others, because the wrap-around didn't cover the whole space evenly, your example makes a pretty convincing case that it's better to have the truncation effects at one level only, rather than compounding the unevennesses created by composing two truncations! Is there an equally compelling case *in favor* of allowing wraparound alignments? -Bert Halstead From schreibr@riacs.edu Sun Jul 19 10:44:28 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA13210); Sun, 19 Jul 92 10:44:28 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA12654; Sun, 19 Jul 92 08:44:26 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA04753; Sun, 19 Jul 92 08:43:07 PDT Message-Id: <9207191543.AA04753@thor.riacs.edu> Date: Sun, 19 Jul 92 08:43:07 PDT From: Rob Schreiber To: hpff-f90@cs.rice.edu Subject: Replication, etc. >>>> From halstead@crl.dec.com Fri Jul 17 13:38:43 1992 a. What if I want ONE COPY PER PROCESSOR? Replicating onto a template is a funny way to express this. This is the intended semantics of replicated alignments, and in my opinion it is the only useful one -- why you would ever want more than one replica of the same datum on the same processor is beyond me! If the current specifications don't make these intended semantics clear enough, maybe they need to be revised... Okay, that was a weak argument. I admit it! b. Replicating a sequential part (or all of) a COMMON block CANNOT BE DONE using (RE)ALIGN because of (3) below. 3. We are proposing to have sequential variables, and to allow them to be used in some directives. If I ALIGN a sequential variable to a template, the effect will be to make the template sequential, too! This is *not* desirable. Just a quick question: what is a "sequential template" and why don't I want to have one? In other words, what am I allowed to do with other kinds of templates that I'm not allowed to do with sequential templates? I don't understand the answers to these questions, and without understanding them, I don't understand why it's undesirable to allow the kind of alignment that you propose to outlaw. We want to allow linear memory sequences to be distributed in the cyclic(k) manner onto one-dimensional processor arrangements. Also, they can be replicated. But they should not be aligned like this real onedim(1000) chpf$ sequence onedim chpf$ align onedim(i) with template(5000 - 4 * i) This simplest thing then seems to be to disallow these things in alignment directives. On the other hand, chpf$ align onedim(i) with template(100 + i) (only + 1*i allowed) or chpf$ align onedim(i) with template(*, 100 + i, *) seems to be okay. This DOES seem simpler than introducing replication in DISTRIBUTE. Does it make sense to the implementors? Rob From zosel@phoenix.ocf.llnl.gov Mon Jul 20 15:45:14 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA05748); Mon, 20 Jul 92 15:45:14 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA28117; Mon, 20 Jul 92 13:45:20 -0700 Date: Mon, 20 Jul 92 13:45:20 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9207202045.AA28117@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: new common proposal f90 Group Following is the proposal that Schreiber / Kennedy / Swift have been working on to allow a more relaxed interpretation of the impact of equivalence on distribution of common blocks. We will review this proposal in the f90 meeting Thursday AM, so you may want to look thru it beforehand. In the minimum, there are a few typo's to fix. It is possible that they will have a new version for us on Thursday - -mary- ---- From: Rob Schreiber Subject: Sequence/storage Proposal High Performance Fortran: Storage and Sequence-Association Proposal 1.2 Modification: Original ------- R. Swift: March, 1992. Version 1.0 --- R. Swift: April 10, 1992 Version 1.1 --- R. Schreiber, R. Swift: May 8, 1992 Version 1.2 --- R. Schreiber, R. Swift, Ken Kennedy: July 14, 1992 (Restricts concept of sequential COMMON, adds aggregate components to nonsequential COMMON. Liberalizes rules on distribution of sequential storage.) Introduction High Performance Fortran (HPF) proposes to distribute variables across multiple processors in order to help achieve parallel execution performance improvements. Fortran 77 and 90 both specify relationships between the storage for some data elements (via COMMON and EQUIVALENCE), and the order of array elements during association at procedure boundaries (via dummy array arguments). Otherwise, the location of data is not constrained by the language. COMMON and EQUIVALENCE statments constrain the alignment of different data items based on the underlying model of storage units and storage sequences. "Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units." (Standard programming language Fortran ISO/IEC 1539:1991 (E) page 247) The model of storage association is a single linearly addressed memory, based on the traditional SISD processor. It is easy to generate examples where this model can cause gross inefficiencies for architectures where storage for variables is distributed. Sequence association refers to the order of array elements that Fortran requires when an array expression or array element is associated with a dummy array argument that is explicit-shaped or assumed-sized. "The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, ..." (ISO/IEC 1539:1991 (E) page 174) As with storage association, sequence association is based on a linearly addressed memory; it can cause excessive overhead for distributed arrays. Because of the large costs involved in supporting storage and sequence association on distributed-memory architectures, this proposal is based on the idea that neither sequence nor storage association applies to distributed applies. Nevertheless, as an aid to porting Fortran 77 codes, this proposal allows codes that rely on sequence and storage association to be valid in HPF. Some modification to existing Fortran 77 codes *will* be necessary. PROPOSAL I. Definitions De-1. Variables (including scalars and arrays of all types, including derived ones) are either sequential or nonsequential. Sequential variables have the properties of storage association and sequence association. Nonsequential variables do not have the properties of storage association and sequence association. De-2. Common blocks are either sequential or nonsequential. A sequential COMMON block has the properties of storage association and sequence association throughout its extent. A nonsequential COMMON block does not have the properties of storage association or sequence association globally. There may be, however, aggregates within the COMMON block, created by equivalences, that do have these properties. De-3. Data distribution attributes are alignment and processor distribution of scalars and array elements in a distributed-memory system. De-4. A variable is distributable or nondistributable. Distributable variables are allowed to appear in HPF explicit distribution directives (EDD): ALIGN, REALIGN, REALIGNABLE, DISTRIBUTE, REDISTRIBUTE, and REDISTRIBUTABLE. De-5. An explicitly distributed variable is any distributable variable that appears in an HPF EDD that specifies its data distribution attributes in the program unit it is declared in. De-6. An implicitly distributed variable is any distributable variable that does not derive its data distribution attributes from any HPF EDD in the program unit it is declared in. End of Definitions Discussion of Definitions. Every variable will have some distribution. A programmer may indicate preferred distributions using directives only for distributable variables. An HPF program may contain both sequential and nonsequential variables and COMMON blocks. It may contain distributable and nondistributable variables. As discussed in Rule St-3 (see Section II) A sequential variable may not be aligned nor may it be used to refer to its associated template in an align directive. In most cases, a sequential variable may not occur in any EDD at all. The one exception is that a sequential, one-dimensional local variable that is equivalenced to an aggregate distribution component of a COMMON block may occur in some restricted form of the distribution directives. There may be other reasons for restricting distributability. For example, TARGET variables may be nondistributable, but they do not, by virtue of the TARGET attribute, acquire sequence and storage association properties. A consequence of Rule St-1 (see Section II) is that sequential COMMON blocks contain only sequential variables; nonsequential COMMON blocks contain nonsequential and sequential variables. The compiler will insure that sequence and storage association operates correctly for sequential arrays and COMMON blocks by limiting the types of implicit distributions that are employed for them. The situation for COMMON blocks is then: ---------------------------------------------------------------- COMMON BLOCK | Component | Whole Block | Variables | ---------------------------------------------------------------- | | Sequential | Sequential, | COMMON blocks may not | not distributable | appear inb EDDs ---------------------------------------------------------------- | Sequential | | aggregates and | Nonsequential | nonsequential vbls; | May not appear in | distributable | EDDs ---------------------------------------------------------------- The sequential and distributable attributes are not applicable to templates. End of Discussion of Definitions II. Storage Association Rule St-1. A variable is SEQUENTIAL if and only if *any* of the following holds: a) it appears in a sequential COMMON block. b) it is a member of an aggregate in a COMMON block; c) it occurs in an EQUIVALENCE statement; d) it is an assumed-size array; e) it is a component of a sequenced type (i.e. a structure with the SEQUENCE attribute); f) it is declared to be sequential in an HPF directive; Rule St-2. A COMMON block is NONSEQUENTIAL if and only if *all* of the following hold: a) it is not explicitly declared sequential; b) every instance of it has exactly the same number of distribution components with exactly the same sequence of lengths (see definitions below); and c) the type, shape, and distribution attributes of any explicitly distributed distribution component are the same in every scoping unit in which the COMMON block occurs. Definition of "distribution components": A distribution component of a COMMON block is a sequence of consectutive component variables. A consective pair A, B of component variables are in the same distribution component if there is a local array variable X equivalenced to one or more component variables in such a way that, if the COMMON block were a FORTRAN 90 COMMON block, then one or more elements of both A and B would be storage associated with elements of X. A COMMON block explicitly declared sequential has one distribution component, an aggregate consisting of the entire COMMON block. Examples: IMPLICIT DOUBLE PRECISION (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150) Ex 1: Four distribution components: (A, B), C, D, E EQUIVALENCE ( A(1), Y(1) ) Ex 2: Three distribution components: A (B, C, D), E EQUIVALENCE ( B(100), Y(1) ) Ex 3: Five distribution components: A, B, C, D, E EQUIVALENCE ( E(1), Y(1) ) Ex 4: Two distribution components: (A, B, C, D), E EQUIVALENCE ( A(51), X(1) ) ( B(100), Y(1) ) Ex 5: Two distribution components: (A, B), (C, D, E) EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) Ex 6: An invalid equivalence EQUIVALENCE ( A(1), Y(1) ) ( B(1), Y(51) ) A distribution component may consist of a single variable that is not storage associated with any local. All other distribution components are "aggregates". An aggregate consists of one or more variables that occur in consecutive positions in the COMMON block, and any two adjacent such variables are storage associated with some local. Definition of "Length" of an aggregate: Let the members of the aggregate have lengths L1, ..., Lk. The position in the aggregate of the ith element of the jth variable is i + (L1 + ... + L(j-1)). The length of the aggregate will usually be (L1 + ... + Lk). If, however, an equivalenced local runs past the last element of Ak (which would have to be the last variable in the COMMON block) or the first element of A1 (which would have to be the first variable in the COMMON block), the length may be increased by the amount by which the local extends past the end of the COMMON block. (This occurs in Example 3, below.) Examples: IMPLICIT DOUBLE PRECISION (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150) Ex 1: Lengths are 200, 100, 100, 100 EQUIVALENCE ( A(1), Y(1) ) Ex 2: Lengths are 100, 300, 100 EQUIVALENCE ( B(100), Y(1) ) Ex 3: Lengths are 100, 100, 100, 100, 150 EQUIVALENCE ( E(1), Y(1) ) Ex 4: Lengths are 400, 100 EQUIVALENCE ( A(51), X(1) ) ( B(100), Y(1) ) Rule St-3. A sequential variable may not appear in an HPF ALIGN, REALIGN, or REALIGNABLE directive. The name of a scalar or a one-dimensional sequential local variable, equivalenced to an aggregate distribution component of a COMMON block and having the same length as the aggregate, *may* be used to refer to the associated template in a DISTRIBUTE, REDISTRIBUTE, or REDISTRIBUTABLE directive. (See discussion below for more information.) A multidimensional sequential variable may not appear in any EDD. A sequential variable whose length is smaller than the length of the aggregate to which it belongs may not appear in any EDD. Discussion of Rule St-3: A nonsequential array variable in a nonsequential COMMON is fully distributable. An aggregate in a nonsequential COMMON is a sequential data object. It is distributable (with restrictions due to its sequential attribute) if there exists a one-dimensional array variable equivalenced to some variable in the aggregate, which variable has length exactly equal to the length of the whole aggregate. In this case the entire aggregate can be distributed by distributing this one-dimensional variable. The scheme described here permits any aggregate in a nonsequential COMMON to be distributed by the mechanism of declaring a local, one-dimensional variable to exacly cover the aggregate in storage. Examples: IMPLICIT DOUBLE PRECISION (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150), Z(200), ZZ(300) Ex 1: Lengths are 200, 100, 100, 100 a) Aggregate not distributable EQUIVALENCE ( A(1), Y(1) ) b) Aggregate distributable by distributing Z EQUIVALENCE ( A(1), Y(1) ) EQUIVALENCE ( A(1), Z(1) ) Ex 2: Lengths are 100, 300, 100 a) Aggrgate not distributable EQUIVALENCE ( B(100), Y(1) ) b) Aggregate distributable by distributing ZZ EQUIVALENCE ( B(100), Y(1) ) EQUIVALENCE ( B(1), ZZ(1) ) Ex 3: Lengths are 100, 100, 100, 100, 150 Aggregate distributable by distributing Y EQUIVALENCE ( E(1), Y(1) ) Ex 4: Lengths are 200, 300 a) Aggregates not distributable EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) b) Aggregates distributable by distributing Z and ZZ EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) EQUIVALENCE ( A(1), Z(1) ) ( C(1), ZZ(1) ) Rule St-4. The result variable of an array-valued user-written function is a nonsequential array. It may not appear in any HPF SEQUENCE directive. End of Storage Association Discussion of Storage Association A nonsequential COMMON block is a global collection of aggregates and nonsequential variables. The shape and type of these must match in all occurrences of the COMMON block. A COMMON block that appears as a nonsequential COMMON block in one program unit must not appear as a sequential COMMON block in another program unit of the same executable program. When two occurrences of the same COMMON block have distribution components that differ in number, type, or shape, then it is up to the programmer to make all occurrences of the COMMON block appear to be sequential. In practice there is no difference between: COMMON /LINEAR_STORE/ A(100), B(200) !HPF SEQUENCE /LINEAR_STORE/ and COMMON /LINEAR_STORE/ A(100), B(200) REAL X(300) EQUIVALENCE (X(1), A(1)) and it should be permissible to have these two different declarations in different subprograms. If X is explicitly distributed, however, then the program is not standard conforming. In other words, absent an explcit distribution for X, the implicit distribution of the aggregate (A, B) in the second example should be the same as the implicit distribution of /LINEAR_STORE/ in the first. The following third declaration is also allowed: COMMON /LINEAR_STORE/ A(100), B(200) !HPF SEQUENCE /LINEAR_STORE/ REAL X(300) EQUIVALENCE (X(1), A(1)) A variable in a sequential COMMON block is nondistributable and may not appear in an EDD. A local one-dimensional array equivalenced so that it covers the whole COMMON block may occur in a DISTRIBUTE directives, but may not be REDISTRIBUTABLE. A compiler option (S option) will be provided to make any COMMON block with no explicitly distributed component a sequential COMMON. An alternate option (D option) will be provided to make any COMMON block with no sequential component a nonsequential COMMON. The standard does not specify either as the default. There may well be additional restrictions on distributability, but these are not related to storage or sequence association. For example, it may be determined that POINTER or TARGET variables may not be explicitly distributed. This will *not* imply that variables with the pointer or target attributes are sequential. Thus, COMMON /TRIO/ A(100), B, C POINTER, ARRAY(:) :: B REAL(200,3), TARGET :: C TRIO may be a nonsequential COMMON block, some of whose components may not be allowed in EDDs. Character variables *may* be distributed. See Rule Se-2 below for restrictions. End of Discussion of Storage Association III. Sequence Association Rule Se-1. When an array element or the name of an assumed-size array is used as an actual argument, the associated dummy argument must be a scalar or a sequential array. An array-element designator of a nonsequential array may not be associated with a dummy array argument. Rule Se-2. A character (scalar or array) variable is nonsequential if it conforms to the requirements of Rule St-1. The length of a nonsequential, explicit-length, character dummy argument must be the same as the length of the actual argument. End of Sequence Association Discussion of Sequence Association Change of the length of character variables across a call, as in character (len=100) one_long_word call webster( one_long_word ) subroutine webster( short_dictionary ) character (len=5) short_dictionary( 20 ) is legal in Fortran 77 and Fortran 90. It is allowed provided both actual and dummy are sequential. This may mean that that SEQUENCE directives are needed. Correct Fortran 77 (and henced Fortran 90) codes will require modification according to this proposal. Explicit sequential directives will be needed in some cases where sequence association is required. The ideal method for porting such codes will be to use an array section in the call statement, which will allow both the actual and dummy arrays to be distributable. An alternative would have had all dummy arrays sequential unless explicitly distributed or made nonsequential by directive, as well as all arrays of which an element appears as an actual argument. We hold that this is too conservative and makes it easy to live with bad old code and difficult to write good new code. Another alternative would have allowed sequence association with nonsequential explicit-shape dummy arrays; at runtime the program would detect that an array element was used as the actual argument, and would copy the data into a distributed temporary (if INTENT is not OUT) and copy the data back on return (if INTENT is not IN). This, however, requires that all the dimensions of the explicit-shape dummy match those of the calling routine's array, which will in general cause more data to be copied than is operated on. Consider this Fortran 77 code. SUBROUTINE SWAPROWS(A, LDA, B, LDB, DIM2) REAL A(LDA, DIM2), B(LDB, DIM2) C LDA and LDB specified to allow proper addressing of elements of rows REAL TEMP(DIM2) !HPF ALIGN TEMP(I) WITH A(1,I) TEMP = A(1,:) A(1,:) = B(1,:) B(1,:) = TEMP RETURN END REAL A(1000, 300), B(500, 300) CALL SWAPROWS( A(10,1), 1000, B(20,1), 500, 300) The alternate proposal here causes *all* of A and B to be copied. This is not viable, and the Fortran 77 style used here needs to be modified. End of Discussion of Sequence Association END OF PROPOSAL Discussion Many uses of COMMON blocks do not require storage association; they are an artifact of having no other way to achieve global data prior to Fortran 90. These rules result in a one-time cost of straightening out the COMMON blocks into an admittedly restricted style. By restricting the use of COMMON and EQUIVALENCE in this fashion, Fortran code satisfying these rules is Fortran 90 compatible. Many F77 programs will work; we are only specifying which ones will not. Automatic tools to check COMMON and generate the allowable forms are fairly straightforward. Note that these rules encourage users to utilize MODULEs or the same COMMON block declaration statements in multiple program units via the INCLUDE statement. Thus the straightforward use of HPF data distribution facilities should also help to improve the maintainability and reliability of the code. Note that the rules of data objects in Modules are simple compared to COMMON, since Modules entail comparatively few storage association problems (Equivalence and ENTRY). Examples: The syntax is illustrative, but the ability to specify each of these attributes is needed. (The SEQUENCE keyword is derived from the Fortran 90 attribute.) To specify a variable is nonsequential but without specifying a distribution: subroutine one(a,b,n,c) dimension a(100), b(N), c(:), d(1000) cHPF NOSEQUENCE :: a,b,c,d To specify explicitly that a variable is sequential: dimension a(100), b(N), c(:), d(1000) cHPF SEQUENCE :: a,b,c,d To specify a COMMON block is nonsequential: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF NOSEQUENCE :: /two/ To specify explicitly that a COMMON block is sequential: Common /two/ e(100), f(10,10), g(10,100,1000) cHPF SEQUENCE :: / two / c If the directive did not appear, /two/ could be c nonsequential by default, depending on the compiler c (S/D) option. In the following, e is explicitly distributed, g is implicitly distributred, and the aggregate (h, p) is explicitly distributed. /two/ is a nonsequential COMMON block: Common /two/ e(10,10), g(10,100,1000), h(100), p(100) real hp(200) equivalence (hp(1), h(1)) cHPF ALIGN e ... cHPF DISTRIBUTE hp CYCLIC(2) From schreibr@riacs.edu Thu Jul 23 12:44:33 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA15794); Thu, 23 Jul 92 12:44:33 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA13776; Thu, 23 Jul 92 10:44:22 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA05480; Thu, 23 Jul 92 10:42:59 PDT Message-Id: <9207231742.AA05480@thor.riacs.edu> Date: Thu, 23 Jul 92 10:42:59 PDT From: Rob Schreiber To: jhm@ecs.southampton.ac.uk Subject: Re: Comments on sequence and storage associated COMMON Cc: gls@think.com, hpff-f90@cs.rice.edu On sequence and storage association, From John Merlin: **** In fact, such data will have to be communicated or ***** **** remapped virtually every time they're referenced!!! ***** That is what Rick Swift has been claiming, but Andy and Tom still claim it is important to allow users to specify replication of a linear object. However, for maximum efficiency on vector machines the array was flattened-out wherever possible, always across procedure boundaries, often to a one-dimensional vector. But there are other good uses in F77, too. It was the best way to pass a subarray to a subroutine. Perhaps a usage survey would be very valuable, especially as a lot of codes will be ported from vector machines to HPF, I imagine. We did one, and there are users who are afraid to give it up all at once, since there codes that make heavy use of it. (4) Finally, if the concensus is to stick with the current proposal for sequence and storage association for common blocks, I implore you to change the default to NO_SEQUENCE_ASSOCIATION and NO_STORAGE_ASSOCIATION. That way, if I do the 'right thing' and declare my common block data the same way in every program unit I can distribute it without pain. I concur with Richard Schapiro, in that I view common block data as simply "a funny way of passing arguments to subprograms". I want to be able to distribute my arrays the same whether they're dummy parameters, local or global---without extra horrible directives. Let those who use sequence and storage association have the pain of all that typing! :-) That is what we intend. In fact, it's arguable that the only directives should be for SEQUENCE_ASSOCATION and STORAGE_ASSOCIATION---there shouldn't be a need for special directives if these features aren't used. Also, why are there two directives---is any different action taken if there is only sequence or only storage assocation but not both? If not, you could merge the directives into one: !HPF$ SEQUENCE_ASSOCIATION_AND_OR_STORAGE_ASSOCATION It will probably be CHPF$ SEQUENCE /FOO/ From schreibr@riacs.edu Mon Aug 3 12:14:28 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA21170); Mon, 3 Aug 92 12:14:28 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA08862; Mon, 3 Aug 92 10:14:19 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA01653; Mon, 3 Aug 92 10:14:17 PDT Message-Id: <9208031714.AA01653@thor.riacs.edu> Date: Mon, 3 Aug 92 10:14:17 PDT From: Rob Schreiber To: zosel@phoenix.ocf.llnl.gov Subject: Re: report Cc: hpff-distribute@cs.rice.edu, hpff-f90@cs.rice.edu Mary Zosel reports this from the meeting: Pijush's example ... too surprising that C can be mapped where we have common A(100), B(100), C(100) Dim X(100) EQV (X, A(50)) in routine 1 common Q(50), R(150), C(100) Dim X(100) EQV (X,R) in routine 2 According to the draft I sent before the meeting, the common block is SEQUENTIAL, becouse it fails to have the same set of distribution components in all instances. In the first, there are two distribution components, of lengths 200, 100. In the second, there are three, of lengths 50, 150, 100. SO, C cannot be distributed, since it is a sequential variable by virtue of its membership in a sequential common block. The rule is that a distribution component contains ALL of each and every variable that is a part of it, so all of A and B are included in the component formed when X is equivalenced to A(50) (first instance above). BUT if we just have common A(100), B(100), C(100) common Q(50), R(150), C(100) in two different routines - C cannot be mapped, becaused it isn't saved by the messy equivalence. Right, it can't be mapped. There is no way to save this one, sorry. Next case. Rob From zosel@phoenix.ocf.llnl.gov Mon Aug 24 18:13:39 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA06181); Mon, 24 Aug 92 18:13:39 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA21282; Mon, 24 Aug 92 16:13:43 -0700 Date: Mon, 24 Aug 92 16:13:43 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9208242313.AA21282@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: storage update Fortran 90 HPF group. One of the things missing from the storage association proposal was the syntax for the SEQUENCE, NOSEQUENCE directives. I have taken a crack at adding that part, as well as restoring a few motivating remarks in the discussion session. See draft proposal below - section II is modified. I would be happy for someone to suggest a better syntatic category name than association-name-list. I believe that other edits were also in the process of happening at the end of the meeting, but I do not have those. I am hoping that Rick and Maureen have the notes on those. I have a latex version from David Loveman and will be making these changes in that version, unless someone suggests better alternatives or corrections. Does anyone remember other changes that were needed for this proposal? Did we convince ourselves that the keyword SEQUENCE was ok for this directive - and does not conflict with the F90 keyword SEQUENCE? Otherwise, we should use SEQUENTIAL and NONSEQUENTIAL. -mary- --------- revised proposal - text form - -------- High Performance Fortran: Storage and Sequence-Association Proposal 1.4 Modification: Original ------- R. Swift: March, 1992. Version 1.0 --- R. Swift: April 10, 1992 Version 1.1 --- R. Schreiber, R. Swift: May 8, 1992 Version 1.2 --- R. Schreiber, R. Swift, K. Kennedy: July 14, 1992 (Restricts concept of sequential COMMON, adds aggregate components to nonsequential COMMON. Liberalizes rules on distribution of sequential storage.) Version 1.3 ----F90 Group modification (Establish better terminology, additional liberalization for locals, simplify text of prop.) Version 1.4 --- modified by M. Zosel: Aug. 24, 1992 (Expand section with storage association rules to include definition of syntax and expand discussion.) Introduction High Performance Fortran (HPF) proposes to map variables across multiple processors in order to help achieve parallel execution performance improvements. FORTRAN 77 and Fortran 90 both specify relationships between the storage for some data elements (via COMMON and EQUIVALENCE), and the order of array elements during association at procedure boundaries (via dummy array arguments). Otherwise, the location of data is not constrained by the language. COMMON and EQUIVALENCE statements constrain the alignment of different data items based on the underlying model of storage units and storage sequences. "Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units." (Standard programming language Fortran ISO/IEC 1539:1991 (E) page 247) The model of storage association is a single linearly addressed memory, based on the traditional SISD processor. It is easy to generate examples where this model can cause gross inefficiencies for architectures where storage for variables is mapped. Sequence association refers to the order of array elements that Fortran requires when an array expression or array element is associated with a dummy array argument that has an explicit-shape or has an assumed-size. "The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, " (ISO/IEC 1539:1991 (E) page 174) As with storage association, sequence association is based on a linearly addressed memory; it can cause excessive overhead for mapped arrays. As an aid to porting Fortran 77 codes, this proposal allows codes that rely on sequence and storage association to be valid in HPF. Some modification to existing Fortran 77 codes *may* be necessary. PROPOSAL I. Definitions De-1. An aggregate storage sequence consists of all the storage sequences in a group of storage sequences that are associated together by EQUIVALENCE statements or EQUIVALENCE and COMMON statements. A COMMON block explicitly declared sequential has one aggregate storage sequence consisting of the entire COMMON block. De-2. An aggregate variable group is a collection of variables whose storage sequences are associated to an aggregate storage sequence. De-3. The size of an aggregate storage sequence is the number of storage units in the storage sequence (as defined in 14.6.3.1 of the standard). De-4. Variables (including scalars and arrays of all types, including derived types) are either sequential or nonsequential. A variable is sequential if and only if *any* of the following holds: a) it appears in a sequential COMMON block; b) it is a member of an aggregate variable group; c) it is an assumed-size array; d) it is a component of a sequenced type (i.e. a derived type with the SEQUENCE attribute); e) it is declared to be sequential in an HPF directive; Sequential variables have the properties of storage association and sequence association. Nonsequential variables do not have the properties of storage association and sequence association. De-5: A COMMON block contains a sequence of components. Each component is a variable that does not appear in any EQUIVALENCE statement or it is an aggregate variable group. COMMON blocks are either sequential or nonsequential. A COMMON block is nonsequential if and only if *all* of the following hold: a) it is not explicitly declared sequential in any program unit in which it appears; b) every instance of the COMMON block has exactly the same number of components with each corresponding component having a storage sequence of exactly the same size; and c) the type, shape, and mapping attributes of any explicitly mapped variable aggregate variable group are the same in every program unit in which the COMMON block occurs. A sequential COMMON block has the properties of storage association and sequence association throughout its extent. A nonsequential COMMON block does not have the properties of storage association or sequence association globally. There may be, however, aggregates within the COMMON block, created by EQUIVALENCEs, that do have these properties. Note that sequential COMMON blocks contain only sequential variables; nonsequential COMMON blocks contain nonsequential and sequential variables. De-6. A variable is mappable or nonmappable. A variable is mappable if it *may* appear in an HPF alignment and distribution directive, otherwise it is nonmappable. De-7. A mappable variable is explicitly mapped if it appears in an HPF alignment and distribution directive within the program unit in which it is declared, otherwise it is implicitly mapped. End of Definitions Examples: IMPLICIT REAL (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150) Ex 1: EQUIVALENCE ( A(1), Y(1) ) Four aggregate variable groups: (A, B), C, D, E Sizes are: 200, 100, 100, 100 Ex 2: EQUIVALENCE ( B(100), Y(1) ) Three aggregate variable groups A, (B, C, D), E Sizes are: 100, 300, 100 Ex 3: EQUIVALENCE ( E(1), Y(1) ) Five aggregate variable groups: A, B, C, D, E Sizes are: 100, 100, 100, 100, 150 Ex 4: EQUIVALENCE ( A(51), X(1) ) ( B(100), Y(1) ) Two aggregate variable groups (A, B, C, D), E Sizes are: 400, 100 Ex 5: EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) Two aggregate variable groups: (A, B), (C, D, E) Sizes are: 200, 300 Ex 6: EQUIVALENCE ( A(1), Y(1) ) ( B(1), Y(51) ) An invalid EQUIVALENCE II. Storage Association II.1 Storage Association Directives Two directives are defined to allow a user to declare explicitly that a variable or a common block is to be treated by the compiler as sequential or nonsequential. storage-association-directive is SEQUENCE[::] association-name-list or NOSEQUENCE [::] association-name-list association-name is variable-name or / common-block-name / II.2 Storage Association Rules Rule St-1. A nonsequential array variable is mappable. A variable in an aggregate variable group is mappable if its storage sequence is totally associated with the aggregate storage sequence of the group. Only one variable in an aggregate variable group may be explicitly mapped. Rule St-2. The result variable of an array-valued function that is not an intrinsic is a nonsequential array. It may not appear in any HPF SEQUENCE directive. II.3 Storage Association Discussion Using these rules, arrays in COMMON blocks can be be mapped as long as the components of the COMMON block, as defined by any EQUIVALENCE statements are the same in every program unit that declares the COMMON block. Rule St-1 further allows variables involved in an EQUIVALENCE statement to be mapped by the mechanism of declaring a variable to exactly conver the aggregate variable group and mapping that variable. As the examples below illustrate, there are many ways to use EQUIVALENCE with COMMON blocks that impact mappability of the variables in subtle ways. In order to allow maximum optimization for performance, the default for variables is to consider them mappable. In order to get correct separate compilation for subprograms that use COMMON blocks with different aggregate components in different subprograms, it will be necessary to insert the SEQUENCE directive. This is an example of where a correct FORTRAN 77 or Fortran 90 program will not necessarily be correct, without modication, in HPF. In order to protect the user and to facilite portability of older codes, two implementation options are strongly recommended. First, every implementation should suppy some mechanism to verify that the aggregate variable groups in COMMON are the same across every subprogram if the COMMON contains mapped arrays. This same check should also verify that identical mappings have been selected for the variables in COMMON. Implementations without interprocedural information can use a link-time check. The second implementation option recommended is a global mechanism to declare that all COMMON blocks for a given compilation should be considered sequential. The purpose of this feature is to permit compilation of large old libraries or subprograms where storage association is known to exist without requiring that the code be modified to apply the SEQUENCE directive to every COMMON block. II.4 Storage Association Examples: (NB - these examples have been cleaned up in the latex version) IMPLICIT REAL (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150), Z(200), ZZ(300) Ex 1: EQUIVALENCE ( A(1), Y(1) ) Aggregate is not mappable. Sizes are 200, 100, 100, 100. Ex 2: EQUIVALENCE ( A(1), Y(1) ), ( A(1), Z(1) ) First aggregate is mappable only by mapping Z. Sizes are 200, 100, 100, 100. Ex 3: EQUIVALENCE ( B(100), Y(1) ), ( B(1), ZZ(1) ) Second aggregate is mappable only by mapping Z. Sizes are 100, 300, 100. Ex 4: EQUIVALENCE ( E(1), Y(1) ) Aggregate is mappable by mapping Y. Sizes are 100, 100, 100, 100, 150. Ex 5: EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) Aggregates are not mappable. Sizes are 200, 300. Ex 6: EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) EQUIVALENCE ( A(1), Z(1) ) ( C(1), ZZ(1) ) Aggregates are mappable by mapping Z and ZZ. Sizes are 200, 300 . Ex 7: SUBROUTINE one(a,b,n,c) DIMENSION a(100), b(N), c(:), d(1000) !HPF NOSEQUENCE :: a,b,c,d To specify variables are nonsequential, but without an providing an explicit mapping. Ex 8: DIMENSION a(100), b(N), c(:), d(1000) !HPF SEQUENCE :: a,b,c,d To specify explicitly that a variable is sequential. Ex 9: COMMON /two/ e(100), f(10,10), g(10,100,1000) !HPF NOSEQUENCE :: /two/ To specify a COMMON block is nonsequential. Ex 10: COMMON /two/ e(10,10), g(10,100,1000), h(100), p(100) REAL cover(200) EQUIVALENCE (cover(1), h(1)) !HPF ALIGN e ... !HPF DISTRIBUTE cover (CYCLIC(2)) Here e is explicitly mapped, g is implicitly mapped, and the aggregate (h, p) is explicitly mapped. and /two/ is a nonsequential COMMON block: From zosel@phoenix.ocf.llnl.gov Mon Aug 24 19:31:23 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA07359); Mon, 24 Aug 92 19:31:23 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA21533; Mon, 24 Aug 92 16:32:21 -0700 Date: Mon, 24 Aug 92 16:32:21 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9208242332.AA21533@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: F90 group homework F90 HPF Group We have several action items due for the meeting in two weeks: (1) The second reading of the storage proposal is due. - draft just sent out - additional edits needed - what more? (2) The first reading of anything new for the subset language is due. After the straw poll, the following proposals were needed: - addition of procedureless modules - Fuhler was going to do this, starting with Highnam's original proposal. - interface blocks need to be restricted slightly - a proposal for entity-oriented declarations was to be prepared for the purpose of discussion. (Might be rejected since the strawpoll was in conclusive. (3) The initial draft of the document is now available. I have the postscript version that was posted at titan.cs.rice.edu, in the directory public/HPFF/draft. I have sent Dave some additional text for the introduction. For Chapter 8 - the part on storage association should be relatively readable. I have not yet checked section 8.5 (parameter passage) to see how complete it looks in the document context. We need to decide on the form of Chapter 9 - the Subset chapter. Currently it is Dave's original text which includes discussion of what is in and out of the proposed subset - but this version does not reflect what we have formally approved - for example, it says that the subset includes the object-oriented syntax (what I called entity-oriented above). We have not yet approved this. This document section needs work. I have the latex versions of both chapters. -mary- From zosel@phoenix.ocf.llnl.gov Mon Aug 31 13:18:46 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA10653); Mon, 31 Aug 92 13:18:46 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA11669; Mon, 31 Aug 92 11:18:50 -0700 Date: Mon, 31 Aug 92 11:18:50 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9208311818.AA11669@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: default distributions Cc: ken@rice.edu F90 / storage group: In answering some questions that John Merlin posted as part of a longer message to hpff-distribute ...I identified a problem that we should at least be aware of ... (don't know what fix to propose) ... the default for common blocks seems to be non-sequential and unless a sequential declarative appears, we assume that aggregates all match in size everywhere and that any explicitely mapped aggregates are identically mapped everywhere. this leaves the option for an aggressive compiler to consider creating some interesting mappings for the aggregates (maybe simple arrays) which do NOT appear in explicit mappings. However, our requirement is only for the size to be the same everywhere for these non-explicit items. It seems to me that a compiler is quite like to make a different decision about mapping X(2,512) and Y(32,32) even though they are the same size. --- Should we try to fix this? How? Is it too heavy handed to require that the arrays which are not explicitely mapped all have the same type and shape, as well as size? (This also says something about cover variable requirements). Is it our "default non-sequential" that is getting us in trouble? For "partially mapped" common blocks, we could require that the user insert a !HPF NONSEQUENTIAL declaration to assert that everything else lines up in a nice safe way so that the compiler can take a crack at default distributions. -mary- From zosel@phoenix.ocf.llnl.gov Mon Aug 31 16:41:18 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA17927); Mon, 31 Aug 92 16:41:18 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA13522; Mon, 31 Aug 92 14:41:23 -0700 Date: Mon, 31 Aug 92 14:41:23 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9208312141.AA13522@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: 2nd try - storage ... apology if this is a repeat ... first try ran into some snag at rice and the distribution didn't complete. --- F90 / storage group: In answering some questions that John Merlin posted as part of a longer message to hpff-distribute ...I identified a problem that we should at least be aware of ... (don't know what fix to propose) ... the default for common blocks seems to be non-sequential and unless a sequential declarative appears, we assume that aggregates all match in size everywhere and that any explicitely mapped aggregates are identically mapped everywhere. this leaves the option for an aggressive compiler to consider creating some interesting mappings for the aggregates (maybe simple arrays) which do NOT appear in explicit mappings. However, our requirement is only for the size to be the same everywhere for these non-explicit items. It seems to me that a compiler is quite like to make a different decision about mapping X(2,512) and Y(32,32) even though they are the same size. --- Should we try to fix this? How? Is it too heavy handed to require that the arrays which are not explicitely mapped all have the same type and shape, as well as size? (This also says something about cover variable requirements). Is it our "default non-sequential" that is getting us in trouble? For "partially mapped" common blocks, we could require that the user insert a !HPF NONSEQUENTIAL declaration to assert that everything else lines up in a nice safe way so that the compiler can take a crack at default distributions. -mary- From zosel@phoenix.ocf.llnl.gov Tue Sep 1 21:45:32 1992 Received: from phoenix.ocf.llnl.gov ([134.9.48.6]) by cs.rice.edu (AA13102); Tue, 1 Sep 92 21:45:32 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA22461; Tue, 1 Sep 92 19:45:38 -0700 Date: Tue, 1 Sep 92 19:45:38 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9209020245.AA22461@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: subset language F90 Group Following is text for 4 proposals to change the subset language. Are there other things that should be included? Would you like to suggest changes to these proposals? I will be submitting a modified version of chapter 9 to Loveman for the document on Thursday afternoon with these proposals reflected in the text (clearly marked as proposals only). -mary- --- --- Specific Proposals to consider for the HPF subset language Mary Zosel, Fortran 90 Subgroup, 9/1/92 _______________________________________________________ Proposal #1. Limit the form of interface blocks in the subset language. The HPF subset is required to contain only INTERFACE blocks with no generic-spec or module-procedure-stmt. Discussion: We previously voted to include INTERFACE blocks in the subset language, but the official F90 syntax also includes functionality for declaring interfaces to things like generic names, defined operators, and module procedures. Since these features are not part of the subset language, we should not require an implementation to support these declarations in an INTERFACE block. _____________________________________________________ Proposal #2. Add 3 new intrinsic subroutines to the subset language. Add the intrinsic subroutines DATE_AND_TIME, RANDOM_SEED, and SYSTEM_CLOCK to the list of Fortran 90 intrinsics included in the HPF subset. Discussion: We have already included RANDOM. We should include RANDOM_SEED for completeness. For users interested in performance, one of the most common things they want to do is measure how they are doing. We should provide DATE_AND_TIME and SYSTEM_CLOCK as standard forms of getting clock time. _________________________________________________________ Proposal #3. Add a limited form of MODULES to the subset language. The HPF subset language should include module, with the specification-part only. It should also include the use- stmt, without the rename-list or ONLY specification. Discussion: We have been struggling with the problem of supporting the names of templates and processors in a way that allows them to be used in multiple subroutines. They cannot be passed as arguments or COMMON. The only other way in Fortran 90 to get a scope for a name that is available in multiple subroutines is to use a MODULE. We have also proposed limitations on remapping of arrays in COMMON and arrays remapped across subroutine boundaries are returned to their original mapping on return. Declaring an array in a MODULE is the only mechanism we have for providing a subroutine whose purpose is to remap data arrays. Use of modules for arrays with explicit mappings is also an additional safety / convenience factor over use of arrays in COMMON because of the requirement that the COMMON blocks match up all storage aggregates before they can contain a mappable array. Note: this proposal excludes the ONLY and rename facilities of the USE statement. If HPFF would like to include these features, this proposal is easily amended. __________________________________________________________ Proposal #4. Add data-object oriented declarations to the subset language. Add the new form of Fortran-90 object type declarations to the HPF subset. Specifically, add the type-delcaration- statement, with all forms of type-spec except kind-selector and TYPE(type-name), and all forms of attr-spec except access-spec, TARGET, and POINTER. Discussion: Fortran 90 has two forms of declarations: the FORTRAN 77 style where the attributes are specified on separate statements, and the new style where the attributes can be grouped together and listed in the same line as the data type declaration: REAL, DIMENSION (10,10), SAVE :: X We are using this form of declaration for our directives. For consistency to the user, we should also add this form for regular declarations. The type-spec values included are the types you expect: INTEGER, REAL, DOUBLE PRECISION, COMPLEX, LOGICAL. The attr-spec values are PARAMETER, ALLOCATABLE, DIMENSION, EXTERNAL, INTENT, INTRINSIC, OPTIONAL, and SAVE. The declaration form also allows initialization values to be specified following the declared name. From zosel@phoenix.ocf.llnl.gov Tue Sep 1 22:44:46 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA13701); Tue, 1 Sep 92 22:44:46 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA22627; Tue, 1 Sep 92 20:44:53 -0700 Date: Tue, 1 Sep 92 20:44:53 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9209020344.AA22627@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: subset opinion request F90 group: in the list of things we are proposing to add to the subset language, should we include recursive procedures??? Can an argument be made that in redesigning algorithms for performance that recursive algorithms are sometimes wanted? Do we anticipate any HPFsubset implementations that will not be stack-based in some way --- and hence have difficulty with implementation of recursive procedures??? Currently, this will NOT be on the list to propose to include unless I hear back from some subgroup members who support it. -mary- From mbsh@holstein.fc.hp.com Wed Sep 2 10:28:57 1992 Received: from hpfcla.fc.hp.com by cs.rice.edu (AA20436); Wed, 2 Sep 92 10:28:57 CDT Received: from dancer.fc.hp.com by hpfcla.fc.hp.com with SMTP (1.36.108.3/15.5+IOS 3.20) id AA08612; Wed, 2 Sep 92 09:27:43 -0600 Received: by holstein.fc.hp.com (16.6/15.5+IOS 3.22) id AA27455; Wed, 2 Sep 92 09:28:52 -0600 Date: Wed, 2 Sep 92 09:28:52 -0600 From: Maureen Hoffert Message-Id: <9209021528.AA27455@holstein.fc.hp.com> To: hpff-f90@cs.rice.edu, zosel@phoenix.ocf.llnl.gov Subject: Re: subset opinion request Hello, Here are some general comments and suggestions on the F90 subset and the current F90 sections of the draft as well as comments on your latest proposals: - I agree that recursion is a key feature that most implementations support on current architectures, however, I think they do not support the Fortran 90 form with the accompanying RECURSIVE and RESULT keyword and functionality. I would ask for guidance from the general committee. I would be willing to support this either way. In the current subset definition character arrays are not included. However, in the current storage and sequence proposal character arrays were no longer special cased and are included. Should we now include them in the subset description? In the latest draft from ftp, assumed-size arrays are still listed as not part of the subset. Should this be assumed-shape arrays, or should it remove these from that list. (Assumed-size arrays are in FORTRAN 77.) I am curious for the rationale for including INTENT and OPTIONAL attributes and statements? If these attributes are included, then this is another reason why we would need to include interface blocks, and the concept of explicit interfaces for them. Explicit interfaces are required if the optional or keyword arguments are used. In the current draft document, in section 8.4, the HPF directives used do not have the correct syntax. (They are missing the $ following HPF.) In the current definition of the subset on p. 83 in section 9.2 the KIND selector is included. It was unclear to me if you were now intending to exclude it from the syntax in your description of the type declaration syntax? See notes below on your proposal. In 9.3 of the draft sequence and storage association is included in the list of features NOT in the subset. I suggest that we remove this from the list, or add the qualification that sequence and storage association is included based on the proposal in Chapter 8. I would prefer that they not be included in the list. In the current draft, the statement "object-oriented DATA statement" is not clear to me what it is referring to? As I commented earlier to Mary, I am in favor of SEQUENTIAL and NONSEQUENTIAL so as not to overload or be confused with the current SEQUENCE statement in Fortran 90. In section 9.2, p. 83 of the draft, the list of attribute statements should include: ALLOCATABLE, EXTERNAL, INTRINSIC, DIMENSION, DATA, and IMPLICIT in order to be complete. I imagine that the FORTRAN 77 type statements might have been omitted because they are included in the F77 subset statement. But I suggest that they be included in this list for completeness. Also for sure the following should be included in the attribute list: ALLOCATABLE, EXTERNAL, INTRINSIC. Another nit, but the common style for "FORTRAN 77", has used all upper case, while Fortran 90 has used the mixed case. Comments on your Proposals: On Proposal #1: I like your proposal for interface blocks. You might add what will change in the draft: Proposed change to the draft: Add to Section 9.2 under "procedure features" change "INTERFACE blocks" to be: INTERFACE blocks as defined in 12.3.2.1 without a module-procedure-stmt or a generic-spec. I would also add your rationale as well. On Proposal #2: I accept your suggestions. On Proposal #3: In addition to your rationale, add to 9.2 a new section entitled ". MODULE and USE statements" Modules as defined in 11.3, R1104, but does not include the module-subprogram-part. Module references as defined in 11.3.1 and 11.3.2, R1107, but only includes the syntax and semantics for USE module-name. Note that this excludes the rename-list, and the ONLY qualifier on the use-stmt. On Proposal #4: I suggest that you not use the term object oriented declarations since this is not common terminology and could be misleading since people in the Fortran world are still just becoming familiar with object oriented concepts. I would suggest that you change your wording for Proposal #4 to read: Proposal #4: Add Fortran 90 Type declaration statements (5.1). Add the new form of Fortran 90 type declaration statements which includes allowing attribute specifications in the type statement, and allows data initialization in the type statements. All attr-spec (R503) are included except POINTER, TARGET and access-spec. Note that in the current draft we have included the KIND selector, so we should decide if we include it or not in this proposal. Additional Note: The one syntax aspect that the ALIGN, etc. directives are using is the continuation indicator from the free form syntax. I recommend that we do not extend the F90 subset to include this as well, but we might note this to the larger group, that we still will not be completely consistent. Regards, Maureen From swift@maspar.com Wed Sep 2 18:59:39 1992 Received: from maspar.MasPar.COM by cs.rice.edu (AA09450); Wed, 2 Sep 92 18:59:39 CDT Received: by maspar.MasPar.COM (5.57/Ultrix3.0-C) id AA22927; Wed, 2 Sep 92 16:59:33 -0700 Received: by armada.MasPar.Com (5.57/Ultrix2.0-B) id AA29932; Wed, 2 Sep 92 17:01:03 -0700 Received: by argosy.MasPar.COM (5.57/Ultrix2.4-C) id AA17611; Wed, 2 Sep 92 17:01:16 -0700 Received: by venus.MasPar.Com (5.57/Ultrix2.4-C) id AA11314; Wed, 2 Sep 92 16:55:22 -0700 Date: Wed, 2 Sep 92 16:55:22 -0700 From: swift@maspar.com (Richard Swift) Message-Id: <9209022355.AA11314@venus.MasPar.Com> To: hpff-f90@cs.rice.edu, zosel@phoenix.ocf.llnl.gov Subject: Response to your email questions Mary - I finally finished reading the 100+ email messages that have accumulated from HPFF, X3J3, etc. over the past few weeks, so here are my responses to your proposals: Proposal 1: Interface Blocks Fine by me. Proposal 2: New intrinsics Fine by me, but I wouldn't spend a lot of committee time arguing about it: if people generally agree, OK, otherwise drop it. Proposal 3: Modules Subset I don't know. We must specify how MODULE/USE works with respect to TEMPLATES, etc. in any case. If this would allow us to rid the Storage and Distribution proposals of all the baggage of "aggregate storage sequences" and "similar TEMPLATES" and all the other strange inventions HPFF has devised to "support" separate compilation and funny storage usage, then I would enthusiastically support this idea. If we simply add one more way (albeit the 'right' way) of doing this stuff, I am not very excited about whether it is in the subset or not. As it stands, your proposal is technically reasonable. Proposal 4: Entity-oriented declarations Fine by me. Proposal 5: Recursion Include it; again don't make a big fuss about it. If people agree, fine, otherwise drop it. (Note: I only support the Fortran 90 forms; I oppose anything that is NOT Fortran 90 in this area. We need standardization.) Also, Maureen's comments raised a few points I'd like to comment on: >>In the current subset definition character arrays are not included. >>However, in the current storage and sequence proposal character arrays >>were no longer special cased and are included. Should we now include >>them in the subset description? Leave CHARACTER array and storage features out of the subset: most implementations today do not implement them in parallel. The subset is supposed to help implementors produce a product quickly: including these would just make it harder, and take longer, for extremely little added value to users. >>In the latest draft from ftp, assumed-size arrays are still listed as >>not part of the subset. Should this be assumed-shape arrays, or should >>it remove these from that list. (Assumed-size arrays are in FORTRAN 77.) The idea is that assumed-size arrays are restricted with respect to distribution, so only f77 style use will work. Leaving it out of the subset emphasizes this: perhaps that's good. >>I am curious for the rationale for including INTENT and OPTIONAL >>attributes and statements? If these attributes are included, then this >>is another reason why we would need to include interface blocks, and the >>concept of explicit interfaces for them. Explicit interfaces are >>required if the optional or keyword arguments are used. INTENT can allow the compiler to optimize argument passing: it is very helpful when re-mapping of dummy arguments occurs. OPTIONAL arguments can be useful in writing more efficient subprograms for the same reason: missing OPTIONAL arguments don't need to be re-mapped. Also, these features are simple to implement when you are doing INTERFACE blocks, and implementors may want to design as much of this stuff at once rather than piecemeal it. >>In the current definition of the subset on p. 83 in section 9.2 the >>KIND selector is included. It was unclear to me if you were now >>intending to exclude it from the syntax in your description of the >>type declaration syntax? See notes below on your proposal. KIND of COMPLEX is the only way we can get "DOUBLE COMPLEX": is this important for the HPF subset? >>In 9.3 of the draft sequence and storage association is included >>in the list of features NOT in the subset. I suggest that we remove >>this from the list, or add the qualification that sequence and storage >>association is included based on the proposal in Chapter 8. I would >>prefer that they not be included in the list. I would prefer the subset does NOT allow all the weird storage stuff: this will allow for simple, rapid implementations that may avoid all the complications as users just clean up the COMMON problems once and for all. Can we at least keep the subset simple? (I've just about given up on keeping the full language simple.) >>As I commented earlier to Mary, I am in favor of SEQUENTIAL and >>NONSEQUENTIAL so as not to overload or be confused with the current >>SEQUENCE statement in Fortran 90. The SEQUENCE/NOSEQUENCE keywords were chosen BECAUSE they are the same as the SEQUENCE statement in Fortran 90. They seem to act exactly like the SEQUENCE statement. So if, in the future, you think of deleting the !HPF$ prefix, they turn into F95 statements that mean exactly the right thing. I don't want another new, different keyword. Finally, I will be out of reach of email after Friday Sept 4, so if you cannot get to me before then, see you at the meeting next Wednesday in Dallas. - Rick From zosel@phoenix.ocf.llnl.gov Mon Sep 7 17:16:25 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA19461); Mon, 7 Sep 92 17:16:25 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA01710; Mon, 7 Sep 92 15:16:32 -0700 Date: Mon, 7 Sep 92 15:16:32 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9209072216.AA01710@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: G1 meeting Wednesday Group 1 following are some of the things I would like to resolve Wednesday afternoon --- in case you want to research your answers ahead of time (fat chance), or want to attend another subgroup meeting and just express some opinions via proxy (more likely). As before, we will meet as soon as we have a quorem of a few folks on Wednesday afternoon - perhaps between 1:30 and 2. -mary- --------- proposed discussion agenda --------- Discussion items for HPF Subgroup 1 Meeting - Wed. Sept 9 Fortran 90 Subset (technically first reading) 1. How formal should the subset specification be? How involved in Fortran-90 syntax should we get? 2. Module rename? The short version I wrote up for the document does not propose rename on the USE. The version that Rich Fuhler sent does propose rename. Should rename be in our formal proposal? 3. Changes / additions / deletions to the list of proposed items for formal committee vote: (limit interface block, modules, new intrinsics, F90 form declarations). 4. Does the discussion of HPF extension subset belong in chapter 9? 5. Document editorial form: Any suggestions about editorial work we should do to improve the Fortran 90 / subset discussion in the document? See sections 1.2, 1.4, 2.1 and chapter 9. 6. Technically, this is the "first reading" for the subset. Is there additional work we should do? ------------------------------------------------------------- Storage Association (second reading - final call to get this right) 1. Do we want SEQUENCE and NOSEQUENCE or SEQUENTIAL and NONSEQUENTIAL? Rick Swift says "existing keyword means what we want - avoid new keywords". Maureen Hoffert says "don't overload a keyword with use in a different context". The F90 document uses SEQUENCE as a property of a derived type. It says (R424 - p33) "If SEQUENCE is present, all derived types specified in component definitions must be sequence types." And in (5.1.1.7) "if a derived type has the SEQUENCE property, a scalar entity of the type is a sequence structure." A sequence type is defined in 4.4: By default, no storage sequence is implied by the order of the component definitions (of a derived type)). However, if the definition of a derived type contains a SEQUENCE statment, the type is a sequence type. The order of the component definitions in a sequence type specifies a storage sequence for objects of that type. 4.4.2 says why SEQUENCE is important: if a derived type is used in two different subroutines (with no modules), then the derived type is the same type ONLY if the type name is the same, and it has all the same components, with identical names, shapes, etc. AND the derived type has the SEQUENCE property in both type declarations. 2. Assumptions about arrays with no explicit mappings. (again) Given COMMON /ABC/ X(2,512), Y(10000) in one subroutine, and COMMON /ABC/ X(32,32), Y(10000) in a second subroutine. Suppose also that there is an explicit mapping for Y(BLOCK) in both subroutines, but no explicit mapping for X. By our current rules, the COMMON is nonsequential: the explicitly mapped component (Y) matches in type, shape, etc. and the other component (X) matches in size and number. Question: whose responsibility is it to make sure that the compiler does the right thing in the case of separate compilation? Is it the user's responsibility to declare X sequential to make sure that the compiler is not tempted to optimize and perhaps choose different distributions. Or is it the compiler's responsibility to somehow learn about all instances of ABC before making any optimizations based on distribution of X (beyond some default 1d-blocked distribution)???? 3. Are all the definitions in 8.1 needed? 4. Document editorial form: We need a volunteer to improve section 8.4. The discussion (8.4.2) needs work, possibly with additional examples. 5 Any additional suggestions about editorial work needed for chapter 8, or 1.3.6? From schreibr@riacs.edu Tue Sep 15 16:40:41 1992 Received: from erato.cs.rice.edu by cs.rice.edu (AA04781); Tue, 15 Sep 92 16:40:41 CDT Received: from icarus.riacs.edu by erato.cs.rice.edu (AA17393); Tue, 15 Sep 92 16:40:35 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA04034; Tue, 15 Sep 92 14:40:32 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA07042; Tue, 15 Sep 92 14:40:23 PDT Message-Id: <9209152140.AA07042@thor.riacs.edu> Date: Tue, 15 Sep 92 14:40:23 PDT From: Rob Schreiber To: gls@think.com Subject: Re: Restrict array mappings? Cc: hpff-distribute@erato.cs.rice.edu, hpff-f90@erato.cs.rice.edu I agree that such a split mapping of a double or a default complex shoul be illegal. I dont fully follow your note on when it can happen. Is there not a problem with user defined types like double complex? (COMPLEX(KIND=(KIND(1.d0)))) e.g. What about a sequential common block consisting of a one-dimensional array of a derived type? If the type has the SEQUENCE attribute, it should be okay to split it, otherwise it should not. In general, our thinking about sequential variables has not paid sufficient attention to derived types and arrays thereof. Rob From zosel@phoenix.ocf.llnl.gov Wed Sep 23 14:37:02 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA01996); Wed, 23 Sep 92 14:37:02 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA29428; Wed, 23 Sep 92 12:37:01 -0700 Date: Wed, 23 Sep 92 12:37:01 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9209231937.AA29428@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: subset revision F90 group Following is the text for Chapter 9 that I propose to send in for the post-September-meeting HPF document. Taking a hint from Rob, I have included a "yet-to-do" list as comments on the beginning. I should also have included "spell-check". The last two items are simply mechanical latex items that I don't know how to do - help welcome. -mary- ---- %hpf-subset.tex %list of work needed for this chapter before October meeting. % % comments and volunteers welcome % %- general review of the new text in section x.3 % %- want F90 references added to all of the x.2 items % %- need to research the proper thing to propose about DIM %restrictions. Is it "constant-expressions" or is something %more restrictive required. % %- need to check out NAMELIST in the standard and see if it needs %further commetn. % %-need proposal from the foreign routines people about what %subset restriction to propose. % %-need to learn how to do an item list with a single item so that %NAMELIST doesn't have the empty line following. % %-need to learn how to reference another chapter so I don't have %the hard-reference to Chapter 8 in the text. % %Version of Sept 23, 1992 - D. Loveman, DEC, M. Zosel LLNL \chapter{Subset High Performance Fortran\protect\footnote{Version of Sept 23, 1992 - David Loveman, Digital Equipment Corporation, Mary Zosel LLNL, with assistance from members of Fortran 90 subgroup.}} \label{subset} \section{Overview} High Performance Fortran is defined as full Fortran 90 with restrictions on storage association and augmented by language features in three areas: \begin{itemize} \item directives in the form of structured comments which, although they do not change the meaning of a program, provide information to a compiler to enable optimization, \item a FORALL statement, and \item extended intrinsic functions and library. \end{itemize} This chapter presents a subset of HPF capable of being implemented by multiple implementors more rapidly than the full HPF. A subset implementation will provide a standard interim capability and full HPF implementations should be developed as rapidly as possible. The definition of the subset language is intended to be a minimal requirement. A given implementation may support additional Fortran 90 and HPF features. \section{Fortran 90 Features in Subset High Performance Fortran} \sloppy \begin{itemize} \item FORTRAN 77 standard conforming, except for sequence and storage association. See chapter 8. \item The Fortran 90 definitions of MIL-STD-1753 features: \begin{itemize} \item DO WHILE statement \item END DO statement \item IMPLICIT NONE statement \item INCLUDE statement (line) \item scalar bit manipulation intrinsic functions: IOR, IAND, NOT, IEOR, ISHFT, ISHFTC, BTEST, IBSET, IBCLR, IBITS, MVBITS (subroutine) \item octal and hexadecimal constants for use in DATA statements: O'. . .', Z'. . . ' \end{itemize} \item arithmetic and logical array features \begin{itemize} \item array sections \begin{itemize} \item subscript triplet notation \item vector-valued subscripts \end{itemize} \item array constructors limited to one level of implied DO \item arithmetic and logical operations on whole arrays and array sections \item array assignment \item masked array assignment \begin{itemize} \item WHERE statement \item block WHERE . . . ELSEWHERE construct \end{itemize} \item array-valued external functions \item AUTOMATIC arrays \item ALLOCATABLE arrays and the ALLOCATE and DEALLOCATE statements \item assumed-shape arrays \end{itemize} \item scalar, inquiry, elemental, and transformational intrinsic functions \begin{itemize} \item argument presence inquiry function: PRESENT \item numeric scalar and array elemental functions: ABS, AIMAG, AINT, ANINT, CEILING, CMPLX, CONJG, DBLE, DIM, DPROD, FLOOR, INT, MAX, MIN, MOD, MODULO, NINT, REAL, SIGN \item mathematical scalar and array elemental functions: ACOS, ASIN, ATAN, ATAN2, COS, COSH, EXP, LOG, LOG10, SIN, SINH, SQRT, TAN, TANH \item character scalar functions: CHAR, ICHAR, INDEX, LGE, LGT, LLE, LLT \item bit manipulation elemental functions : BTEST, IAND, IBCLR, IBITS, IBSET, IEOR, IOR, ISHFT, ISHFTC, NOT \item vector and matrix multiply functions: DOT_PRODUCT, MATMUL \item array reduction functions: ALL, ANY, COUNT, MAXVAL, MINVAL, PRODUCT, SUM \item array inquiry functions: ALLOCATED, LBOUND, SHAPE, SIZE, UBOUND \item array construction functions: MERGE, PACK, SPREAD, UNPACK \item array reshape function: RESHAPE \item array manipulation functions: CSHIFT, EOSHIFT, TRANSPOSE \item array location functions: MAXLOC, MINLOC \item intrinsic elemental subroutine: MVBITS \item intrinsic subroutines: DATE_AND_TIME, RANDOM_NUMBER, RANDOM_SEED, SYSTEM_CLOCK \end{itemize} (change to be proposed):{\it For all of the intrinsics which have an optional argument DIM, only values of DIM which deliver known shape are part of the subset. A precise statement of this is needed.} \item declarations \begin{itemize} \item Type declaration statements, with all forms of {\it type-spec} except {\it kind-selector} and TYPE(type-name), and all forms of {\it attr-spec} except {\it access-spec} , TARGET, and POINTER. \item attribute specification statements: ALLOCATABLE, INTENT, OPTIONAL, PARAMETER, SAVE \end{itemize} \item procedure features \begin{itemize} \item INTERFACE blocks with no {\it generic-spec} or {\it module-procedure-stmt} \item optional arguments \item keyword argument passage \end{itemize} \item I/O features \begin{itemize} \item NAMELIST (proposed for consideration at Oct. meeting) \item ... \end{itemize} \item syntax improvements \begin{itemize} \item long (31 character) names \item lower case letters \item use of ``\_'' in names \item ``!'' initiated comments, both full line and trailing \end{itemize} \end{itemize} \section {Discussion of the Fortran 90 Subset Features} There are many Fortran 90 features which are useful and relatively easy to implement, but are not included in the subset language. Features were selected for the subset language for several reasons. The Mil-STD-1753 features have been implemented so widely that many users have forgotten that they are not part of FORTRAN 77. They are included in the HPF subset. Additional syntactic improvements are included, such as long names and the "!" form of comments because of their general usefulness in program documentation, including description of HPF itself. The biggest addition to FORTRAN 77 in the HPF subset language is the inclusion of the array language. A number of vendors have identified the usefulness of array operations to concise expression of parallelism and already support these features. The new storage classes such as allocatable, automatic, and assumed-shape objects are included in the subset. They provide an important alternative to reduce the use of storage association features such as EQUIVALENCE in order to "save space". Interface blocks have been added to the subset in order to facilitate use of the HPF directives across subroutine boundaries. The interface blocks provide a mechanism to specify the expected mapping of data, in addition to the types and intent of the arguments. \section{HPF Features in Subset High Performance Fortran} All HPF directives and language extensions are included in the HPF subset language with the following constraints: \begin{itemize} \item directives for REALIGN, REALIGNABLE, REDISTRIBUTE, and REDISTRIBUTABLE are not required in the subset. \item the {\it for-all-construct} is not part of the subset, leaving only the single statement FORALL. \item the NUMBER_OF_PROCESSORS, PROCESSORS_SHAPE, and ILEN intrinsics are part of the subset. All other new intrinsics are not. \item the addition of an optional DIM argument to the Fortran 90 MAXLOC and MINLOC intrinsics is part of the subset. Only values of DIM which are constant-expressions are part of the subset. \item the HPF library is not required in the subset. \item {\it some statement about limited form of foreign procedures interface}. \item explicit mapping of sequential variables and aggregate covers, as defined in Chapter 8 is not part of the subset. \end{itemize} \section {Discussion of the HPF Extension Subset} The data mapping features of the HPF subset are limited to static mappings, plus the possible remapping of arguments across the interface of subprogram boundaries. Since the subset language does not include MODULES, and COMMON block variables cannot be remapped, this restriction only impacts remapping of local variables and additional remapping of arguments, after the subprogram boundary. Only the simplest version of FORALL is required in the subset. The interface to foreign procedures defined is intended to allow calling of system libraries. A more powerful interface to routines which will operate on data local to a processor not included in the subset. Only the basic intrinsics needed for declarations of variables and mappings are included in the subset, with the full set of extened operations proposed for the library omitted. The restriction on explicit mapping of sequential variables and covers is to avoid possible cases where the mapping might cause spliting of data values across processors. All of these HPF language reductions are made in the spirit of allowing vendors to get a usable (subset) version of HPF to users quickly so that initial experimentation with the language can begin. \fussy \end{document} From schreibr@riacs.edu Fri Oct 9 14:22:13 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA24188); Fri, 9 Oct 92 14:22:13 CDT Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA24204; Fri, 9 Oct 92 12:22:09 PDT Received: by thor.riacs.edu (4.1/2.0N) id AA09002; Fri, 9 Oct 92 12:22:00 PDT Message-Id: <9210091922.AA09002@thor.riacs.edu> Date: Fri, 9 Oct 92 12:22:00 PDT From: Rob Schreiber To: zosel@phoenix.ocf.llnl.gov Subject: Sequence Cc: hpff-f90@cs.rice.edu Dear Mary, Rick pointed out to me that the Sequence Association document does not now address this instance of sequence association: real a(20,20) call foo(a) subroutine foo( b ) real b(2, 10, 3, 6) We need to state that if the rank of the dummy argument differs from the rank of the actual, or if the actual is a scalar and the dummy isnt, then it is an instance of sequence association, AND both the actual and the dummy must be sequential. Can you make the changes, or should I try? If so, send me the draft again! Best regards, Rob From zosel@phoenix.ocf.llnl.gov Tue Oct 20 14:14:17 1992 Received: from phoenix.ocf.llnl.gov by titan.cs.rice.edu (AA10053); Tue, 20 Oct 92 14:14:17 CDT Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA02862; Tue, 20 Oct 92 12:14:22 -0700 Date: Tue, 20 Oct 92 12:14:22 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9210201914.AA02862@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: Wed. meeting subgroup 1 I propose only a short meeting tomorrow - Wednesday - let's try for 4pm - this will allow you to participate in other group discussions. There was no volunteer to add the F90 references to chapter 9 - so I will be finding a table somewhere to work those out earlier in the afternoon, in case anyone wants to assist with that administrivia. Agenda for short meeting ... 1. Review the proposal M. Snyder has made about lexical form of directives --- see the alternate version of section 2.3 at the end of chapter 2. 2. Check the changes R. Schreiber made to chapter 8 --- definitions reworded slightly from what was approved at last meeting, one new rule about distribution of sequential variables, and one new rule about passing arguments. 3. Check chapter 9 changes I made --- added DIM restriction, added namelist, --- hopefully removed all the things we straw-polled out at the last meeting, and put in text for the subset of the HPF extensions. If anyone involved in other subgroups has additional subset proposals to make - based on discussions in other group - please bring them. For each of the above items - we will determine how the items need to be broken out for voting purposes during the full committee meeting. For the subset discussion - I am particularly interested if anyone can think of complications related to addition of NAMELIST to the subset proposed (done by strawvote last time). My 5-minute check of the standard did not come up with anything. -mary- From schreibr@riacs.edu Tue Dec 1 11:28:21 1992 Received: from icarus.riacs.edu by cs.rice.edu (AA12158); Tue, 1 Dec 92 11:28:21 CST Received: from thor.riacs.edu by icarus.riacs.edu (4.1/2.7G) id AA14344; Tue, 1 Dec 92 09:28:10 PST Received: by thor.riacs.edu (4.1/2.0N) id AA01614; Tue, 1 Dec 92 09:28:09 PST Message-Id: <9212011728.AA01614@thor.riacs.edu> Date: Tue, 1 Dec 92 09:28:09 PST From: Rob Schreiber To: hpff-f90@cs.rice.edu Subject: One more time Dear fellow perfectionists: I have made some editorial "improvements" to the sequence/storage chapter (okay, i know that you'll be the judges of that). In the draft that follows, removed material is set off by triple square [[[bracelets]]] brackets, and added material {\bf such as this} is in bold. No need to print it -- there are only a few changes. Just hunt for '[[[' and '{\bf' with your editor. See you next week. Rex, how cold is it there? Rob % Edits by RSS Dec 1. %sequence.tex %Version of Oct. 23, 1992 - R. Swift, MasPar Computer Corporation, R. %Schreiber, RIACS, and K. Kennedy, Rice University, M. Zosel, LLNL, M Hoffert, HP. \chapter{Sequence and Storage Association\protect\footnote{Version of Oct. 23, 1992 - R. Swift, MasPar Computer Corporation, R. Schreiber, RIACS, and K. Kennedy, Rice University, M. Zosel, LLNL, M. Hoffert, HP.}} \label{sequence} \section{Introduction} High Performance Fortran (HPF) allows the mapping of variables across multiple processors in order to improve parallel performance. FORTRAN 77 and Fortran 90 both specify relationships between the storage for some data objects with COMMON and EQUIVALENCE, and the order of array elements during association at procedure boundaries {\bf between actual and dummy arguments}. [[[(dummy array arguments). ]]] Otherwise, the location of data is not constrained by the language. COMMON and EQUIVALENCE statements constrain the alignment of different data items based on the underlying model of storage units and storage sequences. {\bf Italics added.} \begin{quotation} {\em Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units.} --- Standard programming language Fortran ISO/IEC 1539:1991 (E) section 14.6.3.1. \end{quotation} The model of storage association is a single linearly addressed memory, based on the traditional single address space, single memory unit architecture. This model can cause severe inefficiencies on architectures where storage for variables is mapped. Sequence association refers to the order of array elements that Fortran requires when an array expression or array element is associated with a dummy array argument [[[that has an explicit-shape or has an assumed-size]]]. {\bf Italics added.} \begin{quotation} {\em The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, ...} --- ISO/IEC 1539:1991 (E) section 12.4.1.4. \end{quotation} As with storage association, sequence association is [[[based on]]] {\bf a natural concept only in systems with} a linearly addressed memory. As an aid to porting FORTRAN 77 codes, HPF allows codes that rely on sequence and storage association to be valid in HPF. Some modification to existing FORTRAN 77 codes may nevertheless be necessary. \section{Storage Association} \subsection{Definitions} \label{sequence-defs} \begin{enumerate} \item COMMON blocks are either {\it sequential} or {\it nonsequential}, as determined by either explicit directive or compiler default. A sequential COMMON block has a single common block storage sequence. (5.5.2.1) \item An {\it aggregate variable group} is a collection of variables whose storage sequences are parts of a single storage sequence. Variables associated by EQUIVALENCE statements or by a combination of EQUIVALENCE and COMMON statements form an aggregate variable group. The variables of a sequential COMMON block form a single aggregate variable group. \item The {\it size} of an aggregate variable group is the number of storage units in the group's storage sequence (14.6.3.1). \item If there is a member in an aggregate variable group whose storage sequence is totally associated (14.6.3.3) with the storage sequence of the aggregate variable group, that variable is called an {\it aggregate cover}. \item \label{seq-var} Variables are either {\it sequential} or {\it nonsequential}. A variable is {\it sequential} if and only if any of the following holds: \begin{enumerate} \item it appears in a sequential COMMON block; \item it is a member of an aggregate variable group; \item it is an assumed-size array; \item it is a component of a [[[sequence type (i.e. a]]] derived type with the SEQUENCE attribute; \item it is declared to be sequential in an HPF SEQUENCE directive; \end{enumerate} A sequential variable can be storage associated or sequence associated; nonsequential variables cannot. \item A COMMON block contains a sequence of {\it components}. Each component is either an aggregate variable group, or a variable that is not a member of any aggregate variable group. Sequential COMMON blocks contain a single component. Nonsequential COMMON blocks may contain several components that may be nonsequential or sequential variables or aggregate variable groups. \item A variable is {\it explicitly mapped} if it appears in an HPF alignment or distribution directive within the scoping unit in which it is declared; otherwise it is {\it implicitly mapped}. \end{enumerate} \subsection{Examples of Definitions} \CODE IMPLICIT REAL (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150), Z(200) !Example 1: EQUIVALENCE ( A(1), Z(1) ) !Four components: (A, B), C, D, E !Sizes are: 200, 100, 100, 100 !Example 2: EQUIVALENCE ( B(100), Y(1) ) !Three components A, (B, C, D), E !Sizes are: 100, 300, 100 !Example 3: EQUIVALENCE ( E(1), Y(1) ) !Five components: A, B, C, D, E !Sizes are: 100, 100, 100, 100, 150 !Example 4: EQUIVALENCE ( A(51), X(1) ) ( B(100), Y(1) ) !Two components (A, B, C, D), E !Sizes are: 400, 100 !Example 5: EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) !Two components: (A, B), (C, D, E) !Sizes are: 200, 300 !Example 6: EQUIVALENCE (Y(100), Z(1)) ! One aggregate variable group (Y, Z), not involving the COMMON block. ! Size is 299 !Example 7: CHPF$ SEQUENCE /FOO/ ! The COMMON has one component, the AVG consisting of A, B, C, D, and E ! Size is 500 \EDOC % % EQUIVALENCE ( A(1), Y(1) ) ( B(1), Y(51) ) % !An invalid EQUIVALENCE \noindent In Examples 1--6, common block /FOO/ is nonsequential. Aggregate variable groups are shown as components in parenthesess. Aggregate covers are Z in Example 1 and Y in Example 3. \subsection {Storage Association Directives} A SEQUENCE directive is defined to allow a user to declare explicitly that a variable or a COMMON block is to be treated by the compiler as sequential. (COMMON blocks are by default nonsequential. Variables are nonsequential unless Definition 5 applies.) \BNF storage-association-directive \IS SEQUENCE [[::] association-name-list] association-name \IS variable-name \OR / common-block-name / \FNB \subsection {Storage Association Rules} \begin{enumerate} \item A {\it storage-association-directive} with an empty {\it association-name-list} is treated as if it contained the name of all {\it association-name}s in the scoping unit. \item An aggregate cover may be explicitly mapped. If more than one aggregate cover exists for the aggregate variable group, only one may be {\bf explicitly} mapped. \item The only sequential variables that may be explicitly mapped are scalar or one-dimensional variables. Multi-dimensional sequential variables may not be {\bf explicitly} mapped. \item No explicit mapping may be given for an assumed-size dummy argument array. \item No explicit mapping may be given for a component of a user-defined type having the SEQUENCE attribute. \item If a COMMON block is {\it nonsequential}, then all of the following must hold: \begin{enumerate} \item every occurrence of the COMMON block has exactly the same number of components with each corresponding component having a storage sequence of exactly the same size; \item if a component is a nonsequential variable in {\it any} occurrence of the COMMON block, then it must be nonsequential with identical type, shape, and mapping attributes in {\it every} occurrence of the COMMON block; \item if a component is sequential and explicitly mapped (either a variable or an aggregate variable group with an explicitly mapped aggregate cover) in any occurrence of the COMMON block, then it must be sequential and explicitly mapped with identical and mapping attributes in {\it every} occurrence of the COMMON block. In addition, the type and shape of the explicitly mapped variable must be identical in all occurrences. \end{enumerate} \item The result variable of an array-valued function that is not an intrinsic is a nonsequential array. It may not appear in any HPF SEQUENCE directive. \end{enumerate} \subsection{Storage Association Discussion} Under these rules, variables in a COMMON block can be mapped as long as the components of the COMMON block are the same in every scoping unit that declares the COMMON block. Rule 2 also allows variables involved in an EQUIVALENCE statement to be mapped by the mechanism of declaring a one-dimensional array to exactly cover the aggregate variable group and mapping that array. As the examples below illustrate, there are many ways to use EQUIVALENCE with COMMON blocks that impact mappability of the variables in subtle ways. In order to allow maximum optimization for performance, the default for variables is to consider them mappable. In order to get correct separate compilation for scoping units that use COMMON blocks with different aggregate variable groups in different scoping units, it will be necessary to insert the HPF SEQUENCE directive. This is an example of where a correct FORTRAN 77 or Fortran 90 program will not necessarily be correct, without modification, in HPF. In order to protect the user and to facilitate portability of older codes, two implementation options are strongly recommended. First, every implementation should supply some mechanism to verify that the type and shape of every mappable array and the sizes of aggregate variable groups in a COMMON are the same in every scoping unit if the COMMON is not declared to be sequential. This same check should also verify that identical mappings have been selected for the variables in COMMON. Implementations without interprocedural information can use a link-time check. The second implementation option recommended is a global mechanism to declare that all COMMON blocks for a given compilation should be considered sequential unless declared otherwise. The purpose of this feature is to permit compilation of large old libraries or subprograms where storage association is known to exist without requiring that the code be modified to apply the HPF SEQUENCE directive to every COMMON block. Since an HPF program is nonconforming if it specifies any mapping that would cause storage units to be mapped onto more than one abstract processor, this puts a constraint on the sequential variables and aggregate covers that can be mapped. In particular, programs [[[which might cause]]] {\bf that direct} double precision or complex arrays to be mapped so [[[they]]] {\bf that array elements} are split because of some EQUIVALENCE statement {\bf or COMMON block layout} are nonconforming. \subsection{Examples of Storage Association} \CODE IMPLICIT REAL (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150), Z(200), ZZ(300) EQUIVALENCE ( A(1), Y(1) ) !Aggregate variable group is not mappable. !Sizes are 200, 100, 100, 100. EQUIVALENCE ( B(100), Y(1) ), ( B(1), ZZ(1) ) !Aggregate variable group is mappable only by mapping ZZ. !ZZ is an aggregate cover for B, C, D, and Y. !Sizes are 100, 300, 100. EQUIVALENCE ( E(1), Y(1) ) !Aggregate variable group is mappable by mapping Y. !Sizes are 100, 100, 100, 100, 150. COMMON /TWO/ A(20, 40), E(10,10), G(10,100,1000), H(100), P(100) REAL COVER(200) EQUIVALENCE (COVER(1), H(1)) !HPF$ SEQUENCE A !HPF$ ALIGN E ... !HPF$ DISTRIBUTE COVER (CYCLIC(2)) \EDOC \noindent Here A is sequential and implicitly mapped, E is explicitly mapped, G is implicitly mapped, the aggregate cover of the aggregate variable group (H, P) is explicitly mapped. /TWO/ is a nonsequential COMMON block. In another subprogram, the following declarations may occur: \CODE COMMON /TWO/ A(800), E(10,10), G(10,100,1000), Z(200) !HPF$ SEQUENCE A, Z !HPF$ ALIGN E ... !HPF$ DISTRIBUTE Z (CYCLIC(2)) \EDOC \noindent There are four components of the same size in both occurrences. Components one and four are sequential. Components two and four are explicitly mapped, with the same type, shape and mapping attributes. The first component, A, must be declared sequential in both occurrences because its shape is different. It may not be explicitly mapped in either because it is not one-dimensional or scalar in the first. E and G must agree in type and shape. E must have the same explicit mapping and G must have no explicit mapping in both occurrences, since they are nonsequential variables. The fourth component must have the same explicit mapping in both occurrences, and must be made sequential explicitly in the second. \section{Argument Passing and Sequence Association} For actual arguments in a procedure call, Fortran 90 allows an array element (scalar) to be associated with a dummy argument that is an array. It furthermore allows the rank of a dummy argument to differ from the rank of the corresponding actual array argument, in effect reshaping the actual via the subroutine call. Storage sequence properties of Fortran are used to identify the values of the dummy. This feature, carried over from Fortran 77, has been widely used to pass starting addresses of subarrays, rows or columns of a larger array to procedures. For HPF arrays that are potentially mapped across processors, this feature is not {\bf fully} supported. \subsection{Sequence Association Rules} \begin{enumerate} \item When an array element or the name of an assumed-size array is used as an actual argument, the associated dummy argument must be a scalar or a sequential array. An array-element designator of a nonsequential array may not be associated with a dummy array argument. \item When an actual argument is an array and the corresponding dummy argument [[[which]]] differs from [[[that of]]] the actual argument in shape, then the dummy must be declared sequential and the actual must be an entire, sequential array. \item A variable of [[[default]]] type character (scalar or array) [[[variable]]] is nonsequential if it conforms to the requirements of Definition~\ref{seq-var} of Section~\ref{sequence-defs}. [[[The size of a nonsequential, explicit-length, character dummy argument must be the same as the size of the actual argument.]]] {\bf If the length of an explicit-length character dummy argument differs from the length of the actual argument, then both the actual and dummy arguments must be sequential.} \end{enumerate} \subsection{Discussion of Sequence Association} Correct Fortran 77 (and hence Fortran 90) codes might require modification in HPF. Explicit HPF SEQUENCE directives may be needed in some cases where sequence association exists in order for arrays to be mappable. When the rank of the dummy argument and its associated actual differ, the actual may not be an expression. There is no HPF mechanism for declaring that the value of an array-valued expression is sequential. In order to associate such an expression as an actual with a dummy of different rank, the actual must first be assigned to a named array variable that is forced to be sequential according to Definition~\ref{seq-var} of Section~\ref{sequence-defs}. The ideal method for porting such codes will be to use an array section as the actual argument, which will allow both the dummy and its associated actual `to be mappable. Examples: Given \CODE SUBROUTINE HOME (X) DIMENSION X (20,10) \EDOC By rule 1 \CODE CALL HOME (ET (2,1)) \EDOC is legal only if X is declared sequential in HOME {\bf and ET is sequential in the calling routine}. Likewise, by rule 2 \CODE CALL HOME (ET) \EDOC requires either that ET and X are both sequential arrays or that ET is dimensioned exactly the same as X. Special consideration for CHARACTER: Change of the length of character variables across a call, as in \CODE CHARACTER (LEN=100) one_long_word CALL webster ( one_long_word ) SUBROUTINE webster( short_dictionary ) CHARACTER (LEN=5) short_dictionary ( 20 ) \EDOC \noindent is conceptually legal in Fortran 77 and Fortran 90. It is allowed provided both actual and dummy are sequential. This may mean that !HPF$ SEQUENCE directives are needed. %\end{document} From zosel@phoenix.ocf.llnl.gov Wed Dec 2 15:57:50 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA15167); Wed, 2 Dec 92 15:57:50 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA26001; Wed, 2 Dec 92 13:57:53 -0800 Date: Wed, 2 Dec 92 13:57:53 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9212022157.AA26001@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: hpf - f90 group next meeting TO: Fortran-90 Subgroup Chuck forwarded 3 comments received on chapters 8 and 9 --- copies attached at the end of this message. Also, Rob has done some editorial work on chapter 8 which he sent out a few days ago. I have gone thru the comments --- Stanford had a simple query about HPF --- but points out what I think is an oversight. We should list LEN as one of the array-valued functions in the subset. (The scalar verson is part of F77). Metcalf did a wonderful job of editorial proofing. One of his comments is technical rather than editorial --- he claims that the constraints 3,4,5 and 7 on page 92 should be part of the syntax rather than constraints. This will take some research/thought. SO --- here is what I propose for the meeting next week: (1) I will prepare a new draft of chapters 8 and 9 --- will send them out to you when ready. The new drafts will incorporate - Rob's editorial changes for chapter 8 - Metcalf's editorial changes for both chapters - the proposal that LEN be part of the subset - some additional cleanup of 9.4/9.5 inspired by Metcalf comments. - any appropriate additional input I get from you by Friday. (2) We can discuss Metcalf's constraint/syntax proposal. I would welcome anyone who would like to take a crack at syntax for these constraints (most of syntax probably goes in chapter 3). Any takers for this homework??? Maureen? Rex? anyone else? (3) The subject addressed in paragraph 2 under 8.3.2 needs a bit of attention. There is an additional language restriction here under the discussion that really belongs in the "rules". Also picky-picky - and expression can be a primary which can be a simple thing like x(i). This needs to read correctly so (F77 style) array elements can be passed. {if both sides ssequential}. Then we should make the remainder of the restriction match what F90 allows. If F90 allows a user to pass array-valued expressions (slices, constructors, computed values) in to dummys which don't match in rank - then we should require that the dummy be sequential and require that the compiler arrange for a "storage-sequence association-preserving" copy of the expression rather than say it is illegal. (4) any other topics you want to bring up. ---- Please - if any of the others of you are inspired to do some editorial work - see if you can get me suggestions by Friday. Chuck will print a new version of the document based on what he has Monday noon. As usual, I plan to arrive sometime early afternoon Wed. I'll try to send out a message Monday with a suggested meeting time. -mary- -------- >From @ricevm1.rice.edu:METCALF@crnvma.cern.ch Thu Nov 26 02:58:05 1992 Received: from ricevm1.rice.edu by cs.rice.edu (AA13187); Thu, 26 Nov 92 02:58:05 CST Message-Id: <9211260858.AA13187@cs.rice.edu> Received: from RICEVM1.RICE.EDU by ricevm1.rice.edu (IBM VM SMTP V2R2) with BSMTP id 3250; Thu, 26 Nov 92 02:59:15 CST Received: from CERNVM.cern.ch by RICEVM1.RICE.EDU (Mailer R2.08 R208004) with BSMTP id 5898; Thu, 26 Nov 92 02:59:14 CST Received: from CERNVM.CERN.CH (METCALF) by CERNVM.cern.ch (Mailer R2.08) with BSMTP id 7417; Thu, 26 Nov 92 09:58:54 SET Date: Thu, 26 Nov 92 09:40:09 SET From: Michael Metcalf Subject: Ch. 8 To: hpff-comments@cs.rice.edu Ch. 8 P. 89, line 3: delete 'some'; replace 'with' by 'associated through' line 4: add 'statements' after 'ALENCE' lines 8 and 19; add ':' at end of line line 12: delete 'Standrad ... Fortran' P. 90, line 5: move '.' before '(5.5.2.1)' line 6: add 'individual' after 'whose' Point 5., (e): terminate with '.' P. 91, Example 7: change 'C' to '!' and 'AVG' to 'aggregate variable group' P. 92, points 3., 4., 5., and 7. are actually Constraints and should be added to the bnf for compile-time checking point 3: change 'one-dimensional' to 'rank-one' GLOBAL point 5: change 'user-defined' by 'derived-data' point 6: 'nonsequential' in Roman point 7: add 'function' after 'intrinsic' 8.2.5, line 4: move 'exactly' to follow ' cover' P. 93, 2 lines before Example: change 'which' to 'that'; change 'so they' to 'such that their individual numeric storage units' next line: add ',' before 'are' P. 94, 8.3, line 5: add 'argument' after 'dummy' 8.3.1, point 2, line 1: delete 'which' lines 2 and 3: add 'argument' after 'actual' and 'dummy' (twice) point 3: line 1: delete second 'variable' P. 96, paras 2 and 3: add 'argument' after 'actual' and 'dummy' (7 times) para 2, line 2: change 'may' to 'must' line beginning 'the same': delete 'the same' next line: change clause preceding ':' to 'There is a special consideration for variables of type character' last lines: add 'argument' (twice) Mike Metcalf >From npstan@theory.physics.edinburgh.ac.uk Fri Nov 20 08:34:58 1992 Received: from sun2.nsfnet-relay.ac.uk by cs.rice.edu (AA13677); Fri, 20 Nov 92 08:34:58 CST Via: uk.ac.edinburgh.physics.theory; Fri, 20 Nov 1992 13:47:36 +0000 Date: Fri, 20 Nov 92 13:47:25 GMT Message-Id: <11422.9211201347@th.ph.ed.ac.uk> From: Nick Stanford Subject: F90 and subset HPF query To: hpff-comments@cs.rice.edu I am porting some Connection machine code to HPF and have been using Version 0.4 of your draft HPF spec. I have a small query about section 9.2 (Fortran 90 features in subset HPF). Are 'CASE' and 'LEN' included in the subset. They are part of F90, but seem to have been ommitted from the draft. Thanks ============================================================================== Nick Stanford Theoretical Physics PhD Student npstan@th.ph.ed.ac.uk Assistant Warden Room 4309 A flat, J.C.M.B. Holland House, Kings Buildings Pollock Halls, Mayfield Road 18 Holyrood Park Road Edinburgh,Great Britain Edinburgh EH16 5AY (031) 6505221 (031)6671971 ext 2076 =============================================================================== >From @ricevm1.rice.edu:METCALF@crnvma.cern.ch Thu Nov 26 03:51:46 1992 Received: from ricevm1.rice.edu by cs.rice.edu (AA13347); Thu, 26 Nov 92 03:51:46 CST Message-Id: <9211260951.AA13347@cs.rice.edu> Received: from RICEVM1.RICE.EDU by ricevm1.rice.edu (IBM VM SMTP V2R2) with BSMTP id 3293; Thu, 26 Nov 92 03:52:57 CST Received: from CERNVM.cern.ch by RICEVM1.RICE.EDU (Mailer R2.08 R208004) with BSMTP id 6625; Thu, 26 Nov 92 03:52:56 CST Received: from CERNVM.CERN.CH (METCALF) by CERNVM.cern.ch (Mailer R2.08) with BSMTP id 9326; Thu, 26 Nov 92 10:52:27 SET Date: Thu, 26 Nov 92 10:33:59 SET From: Michael Metcalf Subject: Ch. 9 To: hpff-comments@cs.rice.edu Ch. 9 P. 97, 2nd bullet: add 'and construct' before ',' 3rd bullet: add 'a' after 'and' next line: delete 'multiple' 9.2: add lead sentence: 'The items listed here are the features of the HPF subset language.' 1st bullet: add 'All' at beginning, and 'features' before ',' P. 98, line 1: add '4' after '(' The bit manipulation intrinsic functions are listed here a second time P. 99: ditto for MVBITS (and have you considered BIT_SIZE?) Move 1st para to beginning of whole bullet (deleting the hyphen in its 2nd line) 9.3, para 3, line 4: add 'the' before 'de-' para 4, line 3: replace 'to' by 'for' para 5, line 2: delete 'reduce' line 3: change 'in .. space"' to 'for memory management' last line: add 's' to 'intent' P. 100, line 3: replace 'constraints' [a special word] by 'exceptions' bullet 1: delete 'are not ... subset' 2: delete 'is not ... subset' add new bullet: '# the PURE directive.' 3: delete 'is not ... FORALL'; change 'The' to 'As'; delete 'so'; replace 'intrinsics' by 'intrinsic funtions' 4: replace whole by: 'the HPF library from Chapter 7.' 5: replace whole by: 'values of the optional DIM arguments to the Fortran 90 MAXLOC and MINLOC intrinsic functions that are not initialization expressions.' 6: 'extrinsic' in upper case; delete 'are not ... subset' Mike Metcalf From zosel@phoenix.ocf.llnl.gov Wed Dec 2 18:46:49 1992 Received: from phoenix.ocf.llnl.gov by cs.rice.edu (AA18000); Wed, 2 Dec 92 18:46:49 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA27308; Wed, 2 Dec 92 16:46:56 -0800 Date: Wed, 2 Dec 92 16:46:56 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9212030046.AA27308@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: 2 more items Cc: snir@watson.ibm.com To: F90 subgroup Two more items for us to discuss came to my attention since the first note a while ago. I would like to start you thinking about them. (1) Metcalf asked if we had considered BIT_SIZE for the subset. This intrinsic gives back the number of bits in integers for various values of KIND ... without KIND in the subset, I guess it would give back the value of the default integer size. Comments? (2) My records show that we voted not to have the EXTRINSIC directive in the subset. Is this a mistake? We KNOW there is going to be a need to escape HPF for system things, for messages, for ... do we just close our eyes and let vendors do what comes in the subset - or do we at least provide the directive that declares an external being called is not a regular part of the HPFF data-parallel, SPMD world. As the keeper of the subset chapter, I think we should make a recommendation about this to the full committee. -mary- From @ricevm1.rice.edu:METCALF@crnvma.cern.ch Thu Dec 3 03:45:09 1992 Received: from ricevm1.rice.edu by cs.rice.edu (AA24827); Thu, 3 Dec 92 03:45:09 CST Message-Id: <9212030945.AA24827@cs.rice.edu> Received: from RICEVM1.RICE.EDU by ricevm1.rice.edu (IBM VM SMTP V2R2) with BSMTP id 9782; Thu, 03 Dec 92 03:44:44 CST Received: from CERNVM.cern.ch by RICEVM1.RICE.EDU (Mailer R2.08 R208004) with BSMTP id 0531; Thu, 03 Dec 92 03:44:43 CST Received: from CERNVM.CERN.CH (METCALF) by CERNVM.cern.ch (Mailer R2.08) with BSMTP id 2952; Thu, 03 Dec 92 10:45:58 SET Date: Thu, 03 Dec 92 10:45:01 SET From: Michael Metcalf Subject: LEN To: hpff-f90@cs.rice.edu Please note, with respect to Mary's message, that F77 LEN has a scalar argument and delivers a scalar result; the f90 version may have either a scalar or array-valued argument, but still delivers a scalar result (all the elements of the array have the same length). This is the only F77 intrinsic function that is now not elemental but inquiry. Mike Metcalf From chk@cs.rice.edu Thu Dec 3 14:10:16 1992 Received: from by cs.rice.edu (AB05433); Thu, 3 Dec 92 14:10:16 CST Message-Id: <9212032010.AB05433@cs.rice.edu> Date: Thu, 3 Dec 1992 14:18:40 -0600 To: hpff-f90@cs.rice.edu, zosel@phoenix.ocf.llnl.gov (Mary E Zosel) From: chk@cs.rice.edu Subject: Re: 2 more items Cc: snir@watson.ibm.com At 16:46 12/2/92 -0800, Mary E Zosel wrote: >To: F90 subgroup > >Two more items for us to discuss came to my attention since the first >note a while ago. I would like to start you thinking about them. > >(1) Metcalf asked if we had considered BIT_SIZE for the subset. This >intrinsic gives back the number of bits in integers for various values >of KIND ... without KIND in the subset, I guess it would give back the >value of the default integer size. Comments? Sounds reasonable to me. Of course, not defining the result also sounds reasonable (i.e. in full F90, BIT_SIZE(k) doesn't seem to be defined if KIND=k is not in the implementation). >(2) My records show that we voted not to have the EXTRINSIC directive >in the subset. Is this a mistake? We KNOW there is going to be >a need to escape HPF for system things, for messages, for ... do we >just close our eyes and let vendors do what comes in the subset - or >do we at least provide the directive that declares an external being >called is not a regular part of the HPFF data-parallel, SPMD world. >As the keeper of the subset chapter, I think we should make a >recommendation about this to the full committee. > > -mary- My notes agree with yours re: voting EXTRINSICS out. (It appears to have been an official vote, not a straw poll.) My memory is hazy, but I think the objection was to the (fairly strict) semantics imposed, particularly requiring all processors to be involved in the EXTRINSIC call. My notes include an anonymus statement that the original justification (calling system/other language routines) is not precisely true, and Richard Swift's argument that EXTRINSIC is not (was not at the meeting) well-defined. Rich Shapiro (at least) argued that it was needed, pretty much on the same grounds you gave. I tend to agree with Swift on this one - we don't want to require a semantics that may not be solid in the subset. Leaving EXTRINSIC out may mean that a majority of vendors will implement the subset + one feature; that's OK. (Yes, this optimistically assumes they will implement EXTRINSIC functions before DOIT_MYWAY functions.) Chuck From presberg@tc.cornell.edu Thu Dec 3 18:33:35 1992 Received: from theory.TC.Cornell.EDU by cs.rice.edu (AA12578); Thu, 3 Dec 92 18:33:35 CST Received: by theory.TC.Cornell.EDU id AA19511 (5.65c/IDA-1.4.4); Thu, 3 Dec 1992 19:33:33 -0500 Date: Thu, 3 Dec 1992 19:33:33 -0500 From: David Presberg Message-Id: <199212040033.AA19511@theory.TC.Cornell.EDU> To: hpff-f90@cs.rice.edu Subject: re: 2 more items Cc: presberg@tc.cornell.edu, chk@cs.rice.edu References: <9212030046.AA27308@phoenix.ocf.llnl.gov> ------- Start of forwarded message ------- [Resending message that had bad addresses the first time around] Date: Thu, 3 Dec 1992 18:23:18 -0500 From: David Presberg Message-Id: <199212032323.AA18214@theory.TC.Cornell.EDU> To: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Cc: snir@watson.ibm.com, chk%cs.rice.edu.hpff-f90@cs.rice.edu, presberg@tc.cornell.edu Subject: 2 more items On Wed, 2 Dec 92 16:46 Mary E Zosel wrote: > To: F90 subgroup [Although I've not been at the sub-comm. mtgs, I've been following email...] > ... > > (1) Metcalf asked if we had considered BIT_SIZE for the subset. This > intrinsic gives back the number of bits in integers for various values > of KIND ... without KIND in the subset, I guess it would give back the > value of the default integer size. Comments? My reading is that since BIT_SIZE takes an integer argument (no particular reference to non-default KINDs appears in the definition of BIT_SIZE or any of the sections related to it), it can certainly hand back a sensible value for the default integer type. I can certainly see how BIT_SIZE could be very handy since we have ISHFT, etc., all of which are defined with constraints in terms of BIT_SIZE. Most compilers ought to handle an invocation of BIT_SIZE as a "compiler-generated literal", i.e., there is NO burden on library-writers. > (2) My records show that we voted not to have the EXTRINSIC directive > in the subset. ... My records show the vote as: "To remove EXTRINSICs from the subset 11y 8n 4a" [Chuck?] My vague month-and-a-half recollection is that there were some final misgivings about some more wordsmithing that might have still been needed after the October meeting, and that there was a fairly hefty support burden at interfaces and with libraries and/or intrinsics [sic] that might not be absolutely required if a vendor wasn't going to support EXTRINSICs first time out. I guess we all expect that any vendor shipping an "extended subset" will do the standard things in the standardly specified way. Yeah? > ... Is this a mistake? ... > ... > As the keeper of the subset chapter, I think we should make a > recommendation about this to the full committee. ... I think it might be better to NOT reconsider this exclusion at this time, assuming my assumption at the end of my previous remark is valid. > > -mary- > - -- Pres p.s. Mary, you had best bring YOUR copy of the _Fortran 90 Handbook_ next week: I will not be able to attend the meeting. - - ----------------------------------------------------------------- - - David L. Presberg, Parallel Systems Software Engineer, CNSF/TIG - - 740 Engineering and Theory Center Building, Cornell University, - - Ithaca, NY 14853-3801 607-254-8861 presberg@theory.tc.cornell.edu - - Nickname: Pres - - ----------------------------------------------------------------- ------- End of forwarded message ------- From knighten@ssd.intel.com Thu Dec 3 19:22:26 1992 Received: from SSD.intel.com by cs.rice.edu (AA13595); Thu, 3 Dec 92 19:22:26 CST Received: from tualatin.SSD.intel.com by SSD.intel.com (4.1/SMI-4.1) id AA02493; Thu, 3 Dec 92 17:22:25 PST Date: Thu, 3 Dec 92 17:22:24 PST Message-Id: <9212040122.AA02493@SSD.intel.com> Received: by tualatin.SSD.intel.com (4.1/SMI-4.0) id AA08922; Thu, 3 Dec 92 17:22:21 PST From: Bob Knighten Sender: knighten@ssd.intel.com To: hpff-f90@cs.rice.edu Subject: re: 2 more items In-Reply-To: <199212040033.AA19511@theory.TC.Cornell.EDU> References: <199212040033.AA19511@theory.TC.Cornell.EDU> <9212030046.AA27308@phoenix.ocf.llnl.gov> Reply-To: knighten@ssd.intel.com (Bob Knighten) As one of those who voted against including EXTRINSICs in the subset, it was based on the simple observation that it is not likely to be in the early release of our HPF compiler and so including it in the subset would violate the purpose of the subset. -- Bob Robert L. Knighten | knighten@ssd.intel.com Intel Supercomputer Systems Division | 15201 N.W. Greenbrier Pkwy. | (503) 629-4315 Beaverton, Oregon 97006 | (503) 629-9147 [FAX] From @cunyvm.cuny.edu:SNIR@YKTVMV Thu Dec 3 20:50:20 1992 Received: from CUNYVM.CUNY.EDU by cs.rice.edu (AA14288); Thu, 3 Dec 92 20:50:20 CST Message-Id: <9212040250.AA14288@cs.rice.edu> Received: from YKTVMV by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with BSMTP id 7674; Thu, 03 Dec 92 19:37:32 EST Date: Thu, 3 Dec 92 19:38:07 EST From: "Marc Snir" X-Addr: (914) 945-3204 (862-3204) 28-226 IBM T.J. Watson Research Center P.O. Box 218 Yorktown Heights NY 10598 To: hpff-f90@cs.rice.edu Subject: Extrinsics in subset, or not Reply-To: SNIR@watson.ibm.com If the semantics of extrinsics are not well-defined, they should not be in the draft at all. Subset is not "the well defined" subset of HPF, it is the "easier to implement" or "needed earlier" subset of HPF. The proposal I presented was extrinsic interface in subset, local routines, query functions to be used in local routines and HPF support of local routines not in subset. I was under the impression this was accepted at last meeting. If not, I would suggest to accept it. I wholeheartedly agree that a well defined escape mechanism is needed asap, not some time later. From zosel@phoenix.ocf.llnl.gov Fri Dec 4 14:44:05 1992 Received: from phoenix.ocf.llnl.gov by titan.cs.rice.edu (AA11850); Fri, 4 Dec 92 14:44:05 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA08815; Fri, 4 Dec 92 12:43:57 -0800 Date: Fri, 4 Dec 92 12:43:57 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9212042043.AA08815@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: chapter 9 document To: F90 group the following text has an updated copy of chapter 9 --- this includes the hpf macros pasted on the front so you can run it thru docmake. If you have a chance - print it out and see if you can spot more editorial changes or issues we should discuss at the meeting next week. I will send Chuck a copy Monday morning to include in the latest document before the meeting. Any edits you get to me early Monday or before will be included. -mary- --- --- %hpf-freestanding-chapter-header.tex %Version of August 5, 1992 - David Loveman, Digital Equipment Corporation \documentstyle[11pt]{report} \pagestyle{plain} \pagenumbering{arabic} \marginparwidth 0pt \oddsidemargin=.25in \evensidemargin .25in \marginparsep 0pt \topmargin=-.5in \textwidth=6.0in \textheight=9.0in \parindent=2em %the file syntax-macros.tex is physically included below %syntax-macros.tex %Version of July 29, 1992 - Guy Steele, Thinking Machines \newdimen\bnfalign \bnfalign=2in \newdimen\bnfopwidth \bnfopwidth=.3in \newdimen\bnfindent \bnfindent=.2in \newdimen\bnfsep \bnfsep=6pt \newdimen\bnfmargin \bnfmargin=0.5in \newdimen\codemargin \codemargin=0.5in \newdimen\intrinsicmargin \intrinsicmargin=3em \newdimen\casemargin \casemargin=0.75in \newdimen\argumentmargin \argumentmargin=1.8in \def\IT{\it} \def\RM{\rm} \let\CHAR=\char \let\CATCODE=\catcode \let\DEF=\def \let\GLOBAL=\global \let\RELAX=\relax \let\BEGIN=\begin \let\END=\end \def\FUNNYCHARACTIVE{\CATCODE`\a=13 \CATCODE`\b=13 \CATCODE`\c=13 \CATCODE`\d=13 \CATCODE`\e=13 \CATCODE`\f=13 \CATCODE`\g=13 \CATCODE`\h=13 \CATCODE`\i=13 \CATCODE`\j=13 \CATCODE`\k=13 \CATCODE`\l=13 \CATCODE`\m=13 \CATCODE`\n=13 \CATCODE`\o=13 \CATCODE`\p=13 \CATCODE`\q=13 \CATCODE`\r=13 \CATCODE`\s=13 \CATCODE`\t=13 \CATCODE`\u=13 \CATCODE`\v=13 \CATCODE`\w=13 \CATCODE`\x=13 \CATCODE`\y=13 \CATCODE`\z=13 \CATCODE`\[=13 \CATCODE`\]=13 \CATCODE`\-=13} \def\RETURNACTIVE{\CATCODE`\ =13} \makeatletter \def\section{\@startsection {section}{1}{\z@}{-3.5ex plus -1ex minus -.2ex}{2.3ex plus .2ex}{\large\sf}} \def\subsection{\@startsection{subsection}{2}{\z@}{-3.25ex plus -1ex minus -.2ex}{1.5ex plus .2ex}{\large\sf}} \def\@ifpar#1#2{\let\@tempe\par \def\@tempa{#1}\def\@tempb{#2}\futurelet \@tempc\@ifnch} \def\?#1.{\begingroup\def\@tempq{#1}\list{}{\leftmargin\intrinsicmargin}\relax \item[]{\bf\@tempq.} \@intrinsictest} \def\@intrinsictest{\@ifpar{\@intrinsicpar\@intrinsicdesc}{\@intrinsicpar\relax}} \long\def\@intrinsicdesc#1{\list{}{\relax \def\@tempb{ Arguments}\ifx\@tempq\@tempb \leftmargin\argumentmargin \else \leftmargin\casemargin \fi \labelwidth\leftmargin \advance\labelwidth -\labelsep \parsep 4pt plus 2pt minus 1pt \let\makelabel\@intrinsiclabel}#1\endlist} \long\def\@intrinsicpar#1#2\\{#1{#2}\@ifstar{\@intrinsictest}{\endlist\endgroup}} \def\@intrinsiclabel#1{\setbox0=\hbox{\rm #1}\ifnum\wd0>\labelwidth \box0 \else \hbox to \labelwidth{\box0\hfill}\fi} \def\Case(#1):{\item[{\it Case (#1):}]} \def\ {\@ifnextchar({\def\@tempq{#1}\@intrinsicopt}{\item[#1]}} \def\@intrinsicopt(#1){\item[{\@tempq} (#1)]} \def\MATRIX#1{\relax \@ifnextchar,{\@MATRIXTABS{}#1,\@FOO, \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar;{\@MATRIXTABS{}#1,\@FOO; \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar:{\@MATRIXTABS{}#1,\@FOO: \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar.{\hfill\penalty1\null\penalty10000\hskip0pt plus 1filll \@MATRIXTABS{}#1,\@FOO.\penalty-50\@gobble }{\@MATRIXTABS{}#1,\@FOO{ }\hskip0pt plus 1filll\penalty-1}}}}} \def\@MATRIXTABS#1#2,{\@ifnextchar\@FOO{\@MATRIX{#1#2}}{\@MATRIXTABS{#1#2&}}} \def\@MATRIX#1\@FOO{\(\left[\begin{array}{rrrrrrrrrr}#1\end{array}\right]\)} \def\@IFSPACEORRETURNNEXT#1#2{\def\@tempa{#1}\def\@tempb{#2}\futurelet\@ tempc\@ifspnx} { \FUNNYCHARACTIVE \GLOBAL\DEF\FUNNYCHARDEF{\RELAX \DEFa{{\IT\CHAR"61}}\DEFb{{\IT\CHAR"62}}\DEFc{{\IT\CHAR"63}}\RELAX \DEFd{{\IT\CHAR"64}}\DEFe{{\IT\CHAR"65}}\DEFf{{\IT\CHAR"66}}\RELAX \DEFg{{\IT\CHAR"67}}\DEFh{{\IT\CHAR"68}}\DEFi{{\IT\CHAR"69}}\RELAX \DEFj{{\IT\CHAR"6A}}\DEFk{{\IT\CHAR"6B}}\DEFl{{\IT\CHAR"6C}}\RELAX \DEFm{{\IT\CHAR"6D}}\DEFn{{\IT\CHAR"6E}}\DEFo{{\IT\CHAR"6F}}\RELAX \DEFp{{\IT\CHAR"70}}\DEFq{{\IT\CHAR"71}}\DEFr{{\IT\CHAR"72}}\RELAX \DEFs{{\IT\CHAR"73}}\DEFt{{\IT\CHAR"74}}\DEFu{{\IT\CHAR"75}}\RELAX \DEFv{{\IT\CHAR"76}}\DEFw{{\IT\CHAR"77}}\DEFx{{\IT\CHAR"78}}\RELAX \DEFy{{\IT\CHAR"79}}\DEFz{{\IT\CHAR"7A}}\DEF[{{\RM\CHAR"5B}}\RELAX \DEF]{{\RM\CHAR"5D}}\DEF-{\@IFSPACEORRETURNNEXT{{\CHAR"2D}}{{\IT\CHAR"2D}}}} } %%% Warning! Devious return-character machinations in the next several lines! %%% Don't even *breathe* on these macros! {\RETURNACTIVE\global\def\RETURNDEF{\def {\@ifnextchar\FNB{}{\@stopline\@ifnextchar {\@NEWBNFRULE}{\penalty\@M\@startline\ignorespaces}}}}\global\def\@NEWBNFRULE {\vskip\bnfsep\@startline\ignorespaces}\global\def\@ifspnx{\ifx\@tempc\@ sptoken \let\@tempd\@tempa \else \ifx\@tempc \let\@tempd\@tempa \else \let\@tempd\@tempb \fi\fi \@tempd}} %%% End of bizarro return-character machinations. \def\IS{\@stopfield\global\setbox\@curfield\hbox\bgroup \hskip-\bnfindent \hskip-\bnfopwidth \hskip-\bnfalign \hbox to \bnfalign{\unhbox\@curfield\hfill}\hbox to \bnfopwidth{\bf is \hfill}} \def\OR{\@stopfield\global\setbox\@curfield\hbox\bgroup \hskip-\bnfindent \hskip-\bnfopwidth \hbox to \bnfopwidth{\bf or \hfill}} \def\R#1 {\hbox to 0pt{\hskip-\bnfmargin R#1\hfill}} \def\XBNF{\FUNNYCHARDEF\FUNNYCHARACTIVE\RETURNDEF\RETURNACTIVE \def\@underbarchar{{\char"5F}}\tt\frenchspacing \advance\@totalleftmargin\bnfmargin \tabbing \hskip\bnfalign\hskip\bnfopwidth\hskip\bnfindent\=\kill\>\+\@gobblecr} \def\endXBNF{\-\endtabbing} \def\BNF{\BEGIN{XBNF}} \def\FNB{\END{XBNF}} \begingroup \catcode `|=0 \catcode`\\=12 |gdef|@XCODE#1\EDOC{#1|endtrivlist|end{tt}} |endgroup \def\CODE{\begin{tt}\advance\@totalleftmargin\codemargin \@verbatim \def\@underbarchar{{\char"5F}}\frenchspacing \@vobeyspaces \@XCODE} \def\ICODE{\begin{tt}\advance\@totalleftmargin\codemargin \@verbatim \def\@underbarchar{{\char"5F}}\frenchspacing \@vobeyspaces \FUNNYCHARDEF\FUNNYCHARACTIVE \UNDERBARACTIVE\UNDERBARDEF \@XCODE} \def\@underbarsub#1{{\ifmmode _{#1}\else {$_{#1}$}\fi}} \let\@underbarchar\_ \def\@underbar{\let\@tempq\@underbarsub\if\@tempz A\let\@tempq\@underbarchar\fi \if\@tempz B\let\@tempq\@underbarchar\fi\if\@tempz C\let\@tempq\@underbarchar\fi \if\@tempz D\let\@tempq\@underbarchar\fi\if\@tempz E\let\@tempq\@underbarchar\fi \if\@tempz F\let\@tempq\@underbarchar\fi\if\@tempz G\let\@tempq\@underbarchar\fi \if\@tempz H\let\@tempq\@underbarchar\fi\if\@tempz I\let\@tempq\@underbarchar\fi \if\@tempz J\let\@tempq\@underbarchar\fi\if\@tempz K\let\@tempq\@underbarchar\fi \if\@tempz L\let\@tempq\@underbarchar\fi\if\@tempz M\let\@tempq\@underbarchar\fi \if\@tempz N\let\@tempq\@underbarchar\fi\if\@tempz O\let\@tempq\@underbarchar\fi \if\@tempz P\let\@tempq\@underbarchar\fi\if\@tempz Q\let\@tempq\@underbarchar\fi \if\@tempz R\let\@tempq\@underbarchar\fi\if\@tempz S\let\@tempq\@underbarchar\fi \if\@tempz T\let\@tempq\@underbarchar\fi\if\@tempz U\let\@tempq\@underbarchar\fi \if\@tempz V\let\@tempq\@underbarchar\fi\if\@tempz W\let\@tempq\@underbarchar\fi \if\@tempz X\let\@tempq\@underbarchar\fi\if\@tempz Y\let\@tempq\@underbarchar\fi \if\@tempz Z\let\@tempq\@underbarchar\fi\@tempq} \def\@under{\futurelet\@tempz\@underbar} \def\UNDERBARACTIVE{\CATCODE`\_=13} \UNDERBARACTIVE \def\UNDERBARDEF{\def_{\protect\@under}} \UNDERBARDEF \catcode`\$=11 %the following line would allow derived-type component references %FOO%BAR in running text, but not allow LaTeX comments %without this line, write FOO\%BAR %\catcode`\%=11 \makeatother %end of file syntax-macros.tex \title{High Performance Fortran \\ Language Specification} \author{High Performance Fortran Forum} %\date{ } \hyphenation{RE-DIS-TRIB-UT-ABLE sub-script Wil-liam-son} \begin{document} \maketitle \newpage \pagenumbering{roman} \vspace*{4.5in} This is the result of a LaTeX run of a draft of a single chapter of the HPFF Final Report document. \vspace*{3.0in} \copyright 1992 Rice University, Houston Texas. Permission to copy without fee all or part of this material is granted, provided the Rice University copyright notice and the title of this document appear, and notice is given that copying is by permission of Rice University. \tableofcontents \newpage \pagenumbering{arabic} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %put text of chapter here %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %put \end{document} here %hpf-subset.tex %list of work needed for this chapter. % % comments and volunteers welcome % %how to reference another chapter so I don't have %the hard-reference to Chapter 8 in the text. % %Version of Dec. 02, 1992 - D. Loveman, DEC, M. Zosel LLNL \chapter{Subset High Performance Fortran\protect\footnote{Version of Dec. 2, 1992 - David Loveman, Digital Equipment Corporation, Mary Zosel LLNL, with assistance from members of Fortran 90 subgroup.}} \label{subset} \section{Overview} High Performance Fortran is defined as full Fortran 90 with restrictions on storage association and augmented by language features in three areas: \begin{itemize} \item directives in the form of structured comments which, although they do not change the meaning of a program, provide information to a compiler to enable optimization, \item a FORALL statement and construct, and \item extended intrinsic functions and a library. \end{itemize} This chapter presents a subset of HPF capable of being implemented more rapidly than the full HPF. A subset implementation will provide a standard interim capability and full HPF implementations should be developed as rapidly as possible. The definition of the subset language is intended to be a minimal requirement. A given implementation may support additional Fortran 90 and HPF features. \section{Fortran 90 Features in Subset High Performance Fortran} The items listed here are the features of the HPF subset language. For reference, the section numbers from the Fortran 90 standard ISO/IEC 1539:1991 (E) are given along with the related syntax rule numbers. \sloppy \begin{itemize} \item All FORTRAN 77 standard conforming features, except for sequence and storage association. See chapter 8. \item The Fortran 90 definitions of MIL-STD-1753 features: \begin{itemize} \item DO WHILE statement (8.1.4.1.1 / R821) \item END DO statement (8.1.4.1.1./ R825) \item IMPLICIT NONE statement (5.3 / R540) \item INCLUDE line (3.4) \item scalar bit manipulation intrinsic procedures: IOR, IAND, NOT, IEOR, ISHFT, ISHFTC, BTEST, IBSET, IBCLR, IBITS, MVBITS (13.13) \item binary, octal and hexadecimal constants for use in DATA statements (4.3.1.1 / R407 and 5.2.9 / R533) \end{itemize} \item arithmetic and logical array features: \begin{itemize} \item array sections (6.2.2.3 / R618-621) \begin{itemize} \item subscript triplet notation (6.2.2.3.1) \item vector-valued subscripts (6.2.2.3.2) \end{itemize} \item array constructors limited to one level of implied DO (4.5 / R431) \item arithmetic and logical operations on whole arrays and array sections (2.4.3, 2.4,5, and 7.1) \item array assignment (2.4.5, 7.5, 7.5.1.4, and 7.5.1.5) \item masked array assignment (7.5.3) \begin{itemize} \item WHERE statement (7.5.3 / R738) \item block WHERE . . . ELSEWHERE construct (7.5.3 / R739) \end{itemize} \item array-valued external functions (12.5.2.2) \item AUTOMATIC arrays (5.1.2.4.1) \item ALLOCATABLE arrays and the ALLOCATE and DEALLOCATE statements (5.1.2.4.3, 6.3.1 / R622, and 6.3.3 / R631) \item assumed-shape arrays (5,1,2,4,2 / R516) \end{itemize} \item intrinsics: The list of intrinsic functions and subroutines below is a combination of routines which are entirely new to Fortran and routines that have always been part of Fortran, but now have been extended to new argument and result types. The new or extended definitions of these routines are part of the subset. If a FORTRAN 77 routine is not included in this list, then only the original FORTRAN 77 definition is part of the subset. For all of the intrinsics that have an optional argument DIM, only values of DIM which are initialization expressions and hence deliver a known shape at compile time are part of the subset. The intrinsics with this constraint are marked with * in the list below. \begin{itemize} \item argument presence inquiry function: PRESENT (13.10.1) \item numeric elemental functions: ABS, AIMAG, AINT, ANINT, CEILING, CMPLX, CONJG, DBLE, DIM, DPROD, FLOOR, INT, MAX, MIN, MOD, MODULO, NINT, REAL, SIGN (13.10.2) \item mathematical elemental functions: ACOS, ASIN, ATAN, ATAN2, COS, COSH, EXP, LOG, LOG10, SIN, SINH, SQRT, TAN, TANH (13.10.3) \item character functions: CHAR, ICHAR, INDEX, LEN, LGE, LGT, LLE, LLT (13.10.4) \item bit manipulation elemental functions : BTEST, IAND, IBCLR, IBITS, IBSET, IEOR, IOR, ISHFT, ISHFTC, NOT (13.10.10) \item vector and matrix multiply functions: DOT_PRODUCT, MATMUL (13.10.13) \item array reduction functions: ALL*, ANY*, COUNT*, MAXVAL*, MINVAL*, PRODUCT*, SUM* (13.10.14) \item array inquiry functions: ALLOCATED, LBOUND*, SHAPE, SIZE*, UBOUND (13.10.15) \item array construction functions: MERGE, PACK, SPREAD*, UNPACK (13.10.16) \item array reshape function: RESHAPE (13.10.17) \item array manipulation functions: CSHIFT*, EOSHIFT*, TRANSPOSE (13.10.18) \item array location functions: MAXLOC*, MINLOC* (13.10.19) \item intrinsic elemental subroutine: MVBITS (13.9.3, 13.11) \item intrinsic subroutines: DATE_AND_TIME, RANDOM_NUMBER, RANDOM_SEED, SYSTEM_CLOCK (3.11) \end{itemize} \item declarations: \begin{itemize} \item Type declaration statements, with all forms of {\it type-spec} except {\it kind-selector} and TYPE(type-name), and all forms of {\it attr-spec} except {\it access-spec} , TARGET, and POINTER. (5.1 / R501-503, R510) \item attribute specification statements: ALLOCATABLE, INTENT, OPTIONAL, PARAMETER, SAVE (5.2) \end{itemize} \item procedure features: \begin{itemize} \item INTERFACE blocks with no {\it generic-spec} or {\it module-procedure-stmt} (12.3.2.1) \item optional arguments (5.2.2) \item keyword argument passing (12.4.1 /R1212) \end{itemize} \item syntax improvements: \begin{itemize} \item long (31 character) names (3.2.2) \item lower case letters (3.1.7) \item use of ``\_'' in names (3.1.3) \item ``!'' initiated comments, both full line and trailing (3.3.2.1) \end{itemize} \end{itemize} \section {Discussion of the Fortran 90 Subset Features} There are many Fortran 90 features which are useful and relatively easy to implement, but are not included in the subset language. Features were selected for the subset language for several reasons. The Mil-STD-1753 features have been implemented so widely that many users have forgotten that they are not part of FORTRAN 77. They are included in the HPF subset. Additional syntactic improvements are included, such as long names and the "!" form of comments because of their general usefulness in program documentation, including the description of HPF itself. The biggest addition to FORTRAN 77 in the HPF subset language is the inclusion of the array language. A number of vendors have identified the usefulness of array operations for concise expression of parallelism and already support these features. The new storage classes such as allocatable, automatic, and assumed-shape objects are included in the subset. They provide an important alternative to the use of storage association features such as EQUIVALENCE for memory management. Interface blocks have been added to the subset in order to facilitate use of the HPF directives across subroutine boundaries. The interface blocks provide a mechanism to specify the expected mapping of data, in addition to the types and intents of the arguments. There were other Fortran 90 features considered for the subset. Some features such as CASE or NAMELIST were recognized as popular features of Fortran 90, but had no direct bearing on high performance. Other features such as support for double precision complex (via KIND) or procedureless MODULES were rejected because of the perception that the additional implementation complexity might delay release of subset compilers. It was not a goal of HPFF to define an "ideal" subset of Fortran 90 for all purposes. \section{HPF Features NOT in Subset High Performance Fortran} All HPF directives and language extensions are included in the HPF subset language with the following exceptions: \begin{itemize} \item directives for REALIGN, REDISTRIBUTE, and DYNAMIC \item the PROCESSOR_VIEW directive \item the PURE directive \item the {\it for-all-construct} \item the HPF library \item values of the optional DIM arguments to the Fortran 90 MAXLOC and MINLOC intrinsic functions that are not initialization expressions. \item the EXTRINSIC directive, definition of extrinsic procedures, and the Fortran 90 SPMD binding \end{itemize} \section {Discussion of the HPF Extension Subset} The data mapping features of the HPF subset are limited to static mappings, plus the possible remapping of arguments across the interface of subprogram boundaries. Since the subset language does not include MODULES, and COMMON block variables cannot be remapped, this restriction only impacts remapping of local variables and additional remapping of arguments, after the subprogram boundary. Only the simplest version of FORALL statement is required in the subset. Note that the omision of the PURE directive from the subset means that only HPF and Fortran 90 instrinsic functions can be called from the FORALL statement. No other subprograms can be called. Only the intrinsics which are useful for declaration of variables and mapping inquiries are included in the subset. The full set of extended operations proposed for the HPF library is not required. All of these HPF language reductions are made in the spirit of allowing vendors to get a usable (subset) version of HPF to users quickly so that initial experimentation with the language can begin. This list of HPF features excluded from the subset should not be interpretted as requiring implementors to omit the features from the subset. Implementations with as many HPF features as possible are encouraged. The list does, however, establish the features a user should avoid if an HPF application is expected to be move between different HPF subset implementations. \fussy \end{document} From zosel@phoenix.ocf.llnl.gov Fri Dec 4 14:45:16 1992 Received: from phoenix.ocf.llnl.gov by titan.cs.rice.edu (AA11976); Fri, 4 Dec 92 14:45:16 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA08815; Fri, 4 Dec 92 12:43:57 -0800 Date: Fri, 4 Dec 92 12:43:57 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9212042043.AA08815@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: chapter 9 document To: F90 group the following text has an updated copy of chapter 9 --- this includes the hpf macros pasted on the front so you can run it thru docmake. If you have a chance - print it out and see if you can spot more editorial changes or issues we should discuss at the meeting next week. I will send Chuck a copy Monday morning to include in the latest document before the meeting. Any edits you get to me early Monday or before will be included. -mary- --- --- %hpf-freestanding-chapter-header.tex %Version of August 5, 1992 - David Loveman, Digital Equipment Corporation \documentstyle[11pt]{report} \pagestyle{plain} \pagenumbering{arabic} \marginparwidth 0pt \oddsidemargin=.25in \evensidemargin .25in \marginparsep 0pt \topmargin=-.5in \textwidth=6.0in \textheight=9.0in \parindent=2em %the file syntax-macros.tex is physically included below %syntax-macros.tex %Version of July 29, 1992 - Guy Steele, Thinking Machines \newdimen\bnfalign \bnfalign=2in \newdimen\bnfopwidth \bnfopwidth=.3in \newdimen\bnfindent \bnfindent=.2in \newdimen\bnfsep \bnfsep=6pt \newdimen\bnfmargin \bnfmargin=0.5in \newdimen\codemargin \codemargin=0.5in \newdimen\intrinsicmargin \intrinsicmargin=3em \newdimen\casemargin \casemargin=0.75in \newdimen\argumentmargin \argumentmargin=1.8in \def\IT{\it} \def\RM{\rm} \let\CHAR=\char \let\CATCODE=\catcode \let\DEF=\def \let\GLOBAL=\global \let\RELAX=\relax \let\BEGIN=\begin \let\END=\end \def\FUNNYCHARACTIVE{\CATCODE`\a=13 \CATCODE`\b=13 \CATCODE`\c=13 \CATCODE`\d=13 \CATCODE`\e=13 \CATCODE`\f=13 \CATCODE`\g=13 \CATCODE`\h=13 \CATCODE`\i=13 \CATCODE`\j=13 \CATCODE`\k=13 \CATCODE`\l=13 \CATCODE`\m=13 \CATCODE`\n=13 \CATCODE`\o=13 \CATCODE`\p=13 \CATCODE`\q=13 \CATCODE`\r=13 \CATCODE`\s=13 \CATCODE`\t=13 \CATCODE`\u=13 \CATCODE`\v=13 \CATCODE`\w=13 \CATCODE`\x=13 \CATCODE`\y=13 \CATCODE`\z=13 \CATCODE`\[=13 \CATCODE`\]=13 \CATCODE`\-=13} \def\RETURNACTIVE{\CATCODE`\ =13} \makeatletter \def\section{\@startsection {section}{1}{\z@}{-3.5ex plus -1ex minus -.2ex}{2.3ex plus .2ex}{\large\sf}} \def\subsection{\@startsection{subsection}{2}{\z@}{-3.25ex plus -1ex minus -.2ex}{1.5ex plus .2ex}{\large\sf}} \def\@ifpar#1#2{\let\@tempe\par \def\@tempa{#1}\def\@tempb{#2}\futurelet \@tempc\@ifnch} \def\?#1.{\begingroup\def\@tempq{#1}\list{}{\leftmargin\intrinsicmargin}\relax \item[]{\bf\@tempq.} \@intrinsictest} \def\@intrinsictest{\@ifpar{\@intrinsicpar\@intrinsicdesc}{\@intrinsicpar\relax}} \long\def\@intrinsicdesc#1{\list{}{\relax \def\@tempb{ Arguments}\ifx\@tempq\@tempb \leftmargin\argumentmargin \else \leftmargin\casemargin \fi \labelwidth\leftmargin \advance\labelwidth -\labelsep \parsep 4pt plus 2pt minus 1pt \let\makelabel\@intrinsiclabel}#1\endlist} \long\def\@intrinsicpar#1#2\\{#1{#2}\@ifstar{\@intrinsictest}{\endlist\endgroup}} \def\@intrinsiclabel#1{\setbox0=\hbox{\rm #1}\ifnum\wd0>\labelwidth \box0 \else \hbox to \labelwidth{\box0\hfill}\fi} \def\Case(#1):{\item[{\it Case (#1):}]} \def\ {\@ifnextchar({\def\@tempq{#1}\@intrinsicopt}{\item[#1]}} \def\@intrinsicopt(#1){\item[{\@tempq} (#1)]} \def\MATRIX#1{\relax \@ifnextchar,{\@MATRIXTABS{}#1,\@FOO, \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar;{\@MATRIXTABS{}#1,\@FOO; \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar:{\@MATRIXTABS{}#1,\@FOO: \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar.{\hfill\penalty1\null\penalty10000\hskip0pt plus 1filll \@MATRIXTABS{}#1,\@FOO.\penalty-50\@gobble }{\@MATRIXTABS{}#1,\@FOO{ }\hskip0pt plus 1filll\penalty-1}}}}} \def\@MATRIXTABS#1#2,{\@ifnextchar\@FOO{\@MATRIX{#1#2}}{\@MATRIXTABS{#1#2&}}} \def\@MATRIX#1\@FOO{\(\left[\begin{array}{rrrrrrrrrr}#1\end{array}\right]\)} \def\@IFSPACEORRETURNNEXT#1#2{\def\@tempa{#1}\def\@tempb{#2}\futurelet\@ tempc\@ifspnx} { \FUNNYCHARACTIVE \GLOBAL\DEF\FUNNYCHARDEF{\RELAX \DEFa{{\IT\CHAR"61}}\DEFb{{\IT\CHAR"62}}\DEFc{{\IT\CHAR"63}}\RELAX \DEFd{{\IT\CHAR"64}}\DEFe{{\IT\CHAR"65}}\DEFf{{\IT\CHAR"66}}\RELAX \DEFg{{\IT\CHAR"67}}\DEFh{{\IT\CHAR"68}}\DEFi{{\IT\CHAR"69}}\RELAX \DEFj{{\IT\CHAR"6A}}\DEFk{{\IT\CHAR"6B}}\DEFl{{\IT\CHAR"6C}}\RELAX \DEFm{{\IT\CHAR"6D}}\DEFn{{\IT\CHAR"6E}}\DEFo{{\IT\CHAR"6F}}\RELAX \DEFp{{\IT\CHAR"70}}\DEFq{{\IT\CHAR"71}}\DEFr{{\IT\CHAR"72}}\RELAX \DEFs{{\IT\CHAR"73}}\DEFt{{\IT\CHAR"74}}\DEFu{{\IT\CHAR"75}}\RELAX \DEFv{{\IT\CHAR"76}}\DEFw{{\IT\CHAR"77}}\DEFx{{\IT\CHAR"78}}\RELAX \DEFy{{\IT\CHAR"79}}\DEFz{{\IT\CHAR"7A}}\DEF[{{\RM\CHAR"5B}}\RELAX \DEF]{{\RM\CHAR"5D}}\DEF-{\@IFSPACEORRETURNNEXT{{\CHAR"2D}}{{\IT\CHAR"2D}}}} } %%% Warning! Devious return-character machinations in the next several lines! %%% Don't even *breathe* on these macros! {\RETURNACTIVE\global\def\RETURNDEF{\def {\@ifnextchar\FNB{}{\@stopline\@ifnextchar {\@NEWBNFRULE}{\penalty\@M\@startline\ignorespaces}}}}\global\def\@NEWBNFRULE {\vskip\bnfsep\@startline\ignorespaces}\global\def\@ifspnx{\ifx\@tempc\@ sptoken \let\@tempd\@tempa \else \ifx\@tempc \let\@tempd\@tempa \else \let\@tempd\@tempb \fi\fi \@tempd}} %%% End of bizarro return-character machinations. \def\IS{\@stopfield\global\setbox\@curfield\hbox\bgroup \hskip-\bnfindent \hskip-\bnfopwidth \hskip-\bnfalign \hbox to \bnfalign{\unhbox\@curfield\hfill}\hbox to \bnfopwidth{\bf is \hfill}} \def\OR{\@stopfield\global\setbox\@curfield\hbox\bgroup \hskip-\bnfindent \hskip-\bnfopwidth \hbox to \bnfopwidth{\bf or \hfill}} \def\R#1 {\hbox to 0pt{\hskip-\bnfmargin R#1\hfill}} \def\XBNF{\FUNNYCHARDEF\FUNNYCHARACTIVE\RETURNDEF\RETURNACTIVE \def\@underbarchar{{\char"5F}}\tt\frenchspacing \advance\@totalleftmargin\bnfmargin \tabbing \hskip\bnfalign\hskip\bnfopwidth\hskip\bnfindent\=\kill\>\+\@gobblecr} \def\endXBNF{\-\endtabbing} \def\BNF{\BEGIN{XBNF}} \def\FNB{\END{XBNF}} \begingroup \catcode `|=0 \catcode`\\=12 |gdef|@XCODE#1\EDOC{#1|endtrivlist|end{tt}} |endgroup \def\CODE{\begin{tt}\advance\@totalleftmargin\codemargin \@verbatim \def\@underbarchar{{\char"5F}}\frenchspacing \@vobeyspaces \@XCODE} \def\ICODE{\begin{tt}\advance\@totalleftmargin\codemargin \@verbatim \def\@underbarchar{{\char"5F}}\frenchspacing \@vobeyspaces \FUNNYCHARDEF\FUNNYCHARACTIVE \UNDERBARACTIVE\UNDERBARDEF \@XCODE} \def\@underbarsub#1{{\ifmmode _{#1}\else {$_{#1}$}\fi}} \let\@underbarchar\_ \def\@underbar{\let\@tempq\@underbarsub\if\@tempz A\let\@tempq\@underbarchar\fi \if\@tempz B\let\@tempq\@underbarchar\fi\if\@tempz C\let\@tempq\@underbarchar\fi \if\@tempz D\let\@tempq\@underbarchar\fi\if\@tempz E\let\@tempq\@underbarchar\fi \if\@tempz F\let\@tempq\@underbarchar\fi\if\@tempz G\let\@tempq\@underbarchar\fi \if\@tempz H\let\@tempq\@underbarchar\fi\if\@tempz I\let\@tempq\@underbarchar\fi \if\@tempz J\let\@tempq\@underbarchar\fi\if\@tempz K\let\@tempq\@underbarchar\fi \if\@tempz L\let\@tempq\@underbarchar\fi\if\@tempz M\let\@tempq\@underbarchar\fi \if\@tempz N\let\@tempq\@underbarchar\fi\if\@tempz O\let\@tempq\@underbarchar\fi \if\@tempz P\let\@tempq\@underbarchar\fi\if\@tempz Q\let\@tempq\@underbarchar\fi \if\@tempz R\let\@tempq\@underbarchar\fi\if\@tempz S\let\@tempq\@underbarchar\fi \if\@tempz T\let\@tempq\@underbarchar\fi\if\@tempz U\let\@tempq\@underbarchar\fi \if\@tempz V\let\@tempq\@underbarchar\fi\if\@tempz W\let\@tempq\@underbarchar\fi \if\@tempz X\let\@tempq\@underbarchar\fi\if\@tempz Y\let\@tempq\@underbarchar\fi \if\@tempz Z\let\@tempq\@underbarchar\fi\@tempq} \def\@under{\futurelet\@tempz\@underbar} \def\UNDERBARACTIVE{\CATCODE`\_=13} \UNDERBARACTIVE \def\UNDERBARDEF{\def_{\protect\@under}} \UNDERBARDEF \catcode`\$=11 %the following line would allow derived-type component references %FOO%BAR in running text, but not allow LaTeX comments %without this line, write FOO\%BAR %\catcode`\%=11 \makeatother %end of file syntax-macros.tex \title{High Performance Fortran \\ Language Specification} \author{High Performance Fortran Forum} %\date{ } \hyphenation{RE-DIS-TRIB-UT-ABLE sub-script Wil-liam-son} \begin{document} \maketitle \newpage \pagenumbering{roman} \vspace*{4.5in} This is the result of a LaTeX run of a draft of a single chapter of the HPFF Final Report document. \vspace*{3.0in} \copyright 1992 Rice University, Houston Texas. Permission to copy without fee all or part of this material is granted, provided the Rice University copyright notice and the title of this document appear, and notice is given that copying is by permission of Rice University. \tableofcontents \newpage \pagenumbering{arabic} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %put text of chapter here %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %put \end{document} here %hpf-subset.tex %list of work needed for this chapter. % % comments and volunteers welcome % %how to reference another chapter so I don't have %the hard-reference to Chapter 8 in the text. % %Version of Dec. 02, 1992 - D. Loveman, DEC, M. Zosel LLNL \chapter{Subset High Performance Fortran\protect\footnote{Version of Dec. 2, 1992 - David Loveman, Digital Equipment Corporation, Mary Zosel LLNL, with assistance from members of Fortran 90 subgroup.}} \label{subset} \section{Overview} High Performance Fortran is defined as full Fortran 90 with restrictions on storage association and augmented by language features in three areas: \begin{itemize} \item directives in the form of structured comments which, although they do not change the meaning of a program, provide information to a compiler to enable optimization, \item a FORALL statement and construct, and \item extended intrinsic functions and a library. \end{itemize} This chapter presents a subset of HPF capable of being implemented more rapidly than the full HPF. A subset implementation will provide a standard interim capability and full HPF implementations should be developed as rapidly as possible. The definition of the subset language is intended to be a minimal requirement. A given implementation may support additional Fortran 90 and HPF features. \section{Fortran 90 Features in Subset High Performance Fortran} The items listed here are the features of the HPF subset language. For reference, the section numbers from the Fortran 90 standard ISO/IEC 1539:1991 (E) are given along with the related syntax rule numbers. \sloppy \begin{itemize} \item All FORTRAN 77 standard conforming features, except for sequence and storage association. See chapter 8. \item The Fortran 90 definitions of MIL-STD-1753 features: \begin{itemize} \item DO WHILE statement (8.1.4.1.1 / R821) \item END DO statement (8.1.4.1.1./ R825) \item IMPLICIT NONE statement (5.3 / R540) \item INCLUDE line (3.4) \item scalar bit manipulation intrinsic procedures: IOR, IAND, NOT, IEOR, ISHFT, ISHFTC, BTEST, IBSET, IBCLR, IBITS, MVBITS (13.13) \item binary, octal and hexadecimal constants for use in DATA statements (4.3.1.1 / R407 and 5.2.9 / R533) \end{itemize} \item arithmetic and logical array features: \begin{itemize} \item array sections (6.2.2.3 / R618-621) \begin{itemize} \item subscript triplet notation (6.2.2.3.1) \item vector-valued subscripts (6.2.2.3.2) \end{itemize} \item array constructors limited to one level of implied DO (4.5 / R431) \item arithmetic and logical operations on whole arrays and array sections (2.4.3, 2.4,5, and 7.1) \item array assignment (2.4.5, 7.5, 7.5.1.4, and 7.5.1.5) \item masked array assignment (7.5.3) \begin{itemize} \item WHERE statement (7.5.3 / R738) \item block WHERE . . . ELSEWHERE construct (7.5.3 / R739) \end{itemize} \item array-valued external functions (12.5.2.2) \item AUTOMATIC arrays (5.1.2.4.1) \item ALLOCATABLE arrays and the ALLOCATE and DEALLOCATE statements (5.1.2.4.3, 6.3.1 / R622, and 6.3.3 / R631) \item assumed-shape arrays (5,1,2,4,2 / R516) \end{itemize} \item intrinsics: The list of intrinsic functions and subroutines below is a combination of routines which are entirely new to Fortran and routines that have always been part of Fortran, but now have been extended to new argument and result types. The new or extended definitions of these routines are part of the subset. If a FORTRAN 77 routine is not included in this list, then only the original FORTRAN 77 definition is part of the subset. For all of the intrinsics that have an optional argument DIM, only values of DIM which are initialization expressions and hence deliver a known shape at compile time are part of the subset. The intrinsics with this constraint are marked with * in the list below. \begin{itemize} \item argument presence inquiry function: PRESENT (13.10.1) \item numeric elemental functions: ABS, AIMAG, AINT, ANINT, CEILING, CMPLX, CONJG, DBLE, DIM, DPROD, FLOOR, INT, MAX, MIN, MOD, MODULO, NINT, REAL, SIGN (13.10.2) \item mathematical elemental functions: ACOS, ASIN, ATAN, ATAN2, COS, COSH, EXP, LOG, LOG10, SIN, SINH, SQRT, TAN, TANH (13.10.3) \item character functions: CHAR, ICHAR, INDEX, LEN, LGE, LGT, LLE, LLT (13.10.4) \item bit manipulation elemental functions : BTEST, IAND, IBCLR, IBITS, IBSET, IEOR, IOR, ISHFT, ISHFTC, NOT (13.10.10) \item vector and matrix multiply functions: DOT_PRODUCT, MATMUL (13.10.13) \item array reduction functions: ALL*, ANY*, COUNT*, MAXVAL*, MINVAL*, PRODUCT*, SUM* (13.10.14) \item array inquiry functions: ALLOCATED, LBOUND*, SHAPE, SIZE*, UBOUND (13.10.15) \item array construction functions: MERGE, PACK, SPREAD*, UNPACK (13.10.16) \item array reshape function: RESHAPE (13.10.17) \item array manipulation functions: CSHIFT*, EOSHIFT*, TRANSPOSE (13.10.18) \item array location functions: MAXLOC*, MINLOC* (13.10.19) \item intrinsic elemental subroutine: MVBITS (13.9.3, 13.11) \item intrinsic subroutines: DATE_AND_TIME, RANDOM_NUMBER, RANDOM_SEED, SYSTEM_CLOCK (3.11) \end{itemize} \item declarations: \begin{itemize} \item Type declaration statements, with all forms of {\it type-spec} except {\it kind-selector} and TYPE(type-name), and all forms of {\it attr-spec} except {\it access-spec} , TARGET, and POINTER. (5.1 / R501-503, R510) \item attribute specification statements: ALLOCATABLE, INTENT, OPTIONAL, PARAMETER, SAVE (5.2) \end{itemize} \item procedure features: \begin{itemize} \item INTERFACE blocks with no {\it generic-spec} or {\it module-procedure-stmt} (12.3.2.1) \item optional arguments (5.2.2) \item keyword argument passing (12.4.1 /R1212) \end{itemize} \item syntax improvements: \begin{itemize} \item long (31 character) names (3.2.2) \item lower case letters (3.1.7) \item use of ``\_'' in names (3.1.3) \item ``!'' initiated comments, both full line and trailing (3.3.2.1) \end{itemize} \end{itemize} \section {Discussion of the Fortran 90 Subset Features} There are many Fortran 90 features which are useful and relatively easy to implement, but are not included in the subset language. Features were selected for the subset language for several reasons. The Mil-STD-1753 features have been implemented so widely that many users have forgotten that they are not part of FORTRAN 77. They are included in the HPF subset. Additional syntactic improvements are included, such as long names and the "!" form of comments because of their general usefulness in program documentation, including the description of HPF itself. The biggest addition to FORTRAN 77 in the HPF subset language is the inclusion of the array language. A number of vendors have identified the usefulness of array operations for concise expression of parallelism and already support these features. The new storage classes such as allocatable, automatic, and assumed-shape objects are included in the subset. They provide an important alternative to the use of storage association features such as EQUIVALENCE for memory management. Interface blocks have been added to the subset in order to facilitate use of the HPF directives across subroutine boundaries. The interface blocks provide a mechanism to specify the expected mapping of data, in addition to the types and intents of the arguments. There were other Fortran 90 features considered for the subset. Some features such as CASE or NAMELIST were recognized as popular features of Fortran 90, but had no direct bearing on high performance. Other features such as support for double precision complex (via KIND) or procedureless MODULES were rejected because of the perception that the additional implementation complexity might delay release of subset compilers. It was not a goal of HPFF to define an "ideal" subset of Fortran 90 for all purposes. \section{HPF Features NOT in Subset High Performance Fortran} All HPF directives and language extensions are included in the HPF subset language with the following exceptions: \begin{itemize} \item directives for REALIGN, REDISTRIBUTE, and DYNAMIC \item the PROCESSOR_VIEW directive \item the PURE directive \item the {\it for-all-construct} \item the HPF library \item values of the optional DIM arguments to the Fortran 90 MAXLOC and MINLOC intrinsic functions that are not initialization expressions. \item the EXTRINSIC directive, definition of extrinsic procedures, and the Fortran 90 SPMD binding \end{itemize} \section {Discussion of the HPF Extension Subset} The data mapping features of the HPF subset are limited to static mappings, plus the possible remapping of arguments across the interface of subprogram boundaries. Since the subset language does not include MODULES, and COMMON block variables cannot be remapped, this restriction only impacts remapping of local variables and additional remapping of arguments, after the subprogram boundary. Only the simplest version of FORALL statement is required in the subset. Note that the omision of the PURE directive from the subset means that only HPF and Fortran 90 instrinsic functions can be called from the FORALL statement. No other subprograms can be called. Only the intrinsics which are useful for declaration of variables and mapping inquiries are included in the subset. The full set of extended operations proposed for the HPF library is not required. All of these HPF language reductions are made in the spirit of allowing vendors to get a usable (subset) version of HPF to users quickly so that initial experimentation with the language can begin. This list of HPF features excluded from the subset should not be interpretted as requiring implementors to omit the features from the subset. Implementations with as many HPF features as possible are encouraged. The list does, however, establish the features a user should avoid if an HPF application is expected to be move between different HPF subset implementations. \fussy \end{document} From zosel@phoenix.ocf.llnl.gov Fri Dec 4 16:21:06 1992 Received: from phoenix.ocf.llnl.gov by titan.cs.rice.edu (AA15966); Fri, 4 Dec 92 16:21:06 CST Received: by phoenix.ocf.llnl.gov (5.57/LLNL-1.18) id AA18851; Fri, 4 Dec 92 14:21:03 -0800 Date: Fri, 4 Dec 92 14:21:03 -0800 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Message-Id: <9212042221.AA18851@phoenix.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: chapter 8 update To: Fortran 90 subgroup Following is an updated verson of chapter 8 - complete with the document macros so you can just send it thru docmake. This incorporates Rob's editorial changes and Mike Metcalf's, except for moving rules to constraints - will take appropriate action at the meeting for that change. I also changed the first title to match some other chapters and added an "overview" sentence at the end of the first section. (improved sentences welcome). I'll send this on to Chuck Monday morning. An additional edits you spot are welcome - get them to me relatively early Monday. I haven't had a chance to proof-read my own editting on this one yet. -mary- --- --- %hpf-freestanding-chapter-header.tex %Version of August 5, 1992 - David Loveman, Digital Equipment Corporation \documentstyle[11pt]{report} \pagestyle{plain} \pagenumbering{arabic} \marginparwidth 0pt \oddsidemargin=.25in \evensidemargin .25in \marginparsep 0pt \topmargin=-.5in \textwidth=6.0in \textheight=9.0in \parindent=2em %the file syntax-macros.tex is physically included below %syntax-macros.tex %Version of July 29, 1992 - Guy Steele, Thinking Machines \newdimen\bnfalign \bnfalign=2in \newdimen\bnfopwidth \bnfopwidth=.3in \newdimen\bnfindent \bnfindent=.2in \newdimen\bnfsep \bnfsep=6pt \newdimen\bnfmargin \bnfmargin=0.5in \newdimen\codemargin \codemargin=0.5in \newdimen\intrinsicmargin \intrinsicmargin=3em \newdimen\casemargin \casemargin=0.75in \newdimen\argumentmargin \argumentmargin=1.8in \def\IT{\it} \def\RM{\rm} \let\CHAR=\char \let\CATCODE=\catcode \let\DEF=\def \let\GLOBAL=\global \let\RELAX=\relax \let\BEGIN=\begin \let\END=\end \def\FUNNYCHARACTIVE{\CATCODE`\a=13 \CATCODE`\b=13 \CATCODE`\c=13 \CATCODE`\d=13 \CATCODE`\e=13 \CATCODE`\f=13 \CATCODE`\g=13 \CATCODE`\h=13 \CATCODE`\i=13 \CATCODE`\j=13 \CATCODE`\k=13 \CATCODE`\l=13 \CATCODE`\m=13 \CATCODE`\n=13 \CATCODE`\o=13 \CATCODE`\p=13 \CATCODE`\q=13 \CATCODE`\r=13 \CATCODE`\s=13 \CATCODE`\t=13 \CATCODE`\u=13 \CATCODE`\v=13 \CATCODE`\w=13 \CATCODE`\x=13 \CATCODE`\y=13 \CATCODE`\z=13 \CATCODE`\[=13 \CATCODE`\]=13 \CATCODE`\-=13} \def\RETURNACTIVE{\CATCODE`\ =13} \makeatletter \def\section{\@startsection {section}{1}{\z@}{-3.5ex plus -1ex minus -.2ex}{2.3ex plus .2ex}{\large\sf}} \def\subsection{\@startsection{subsection}{2}{\z@}{-3.25ex plus -1ex minus -.2ex}{1.5ex plus .2ex}{\large\sf}} \def\@ifpar#1#2{\let\@tempe\par \def\@tempa{#1}\def\@tempb{#2}\futurelet \@tempc\@ifnch} \def\?#1.{\begingroup\def\@tempq{#1}\list{}{\leftmargin\intrinsicmargin}\relax \item[]{\bf\@tempq.} \@intrinsictest} \def\@intrinsictest{\@ifpar{\@intrinsicpar\@intrinsicdesc}{\@intrinsicpar\relax}} \long\def\@intrinsicdesc#1{\list{}{\relax \def\@tempb{ Arguments}\ifx\@tempq\@tempb \leftmargin\argumentmargin \else \leftmargin\casemargin \fi \labelwidth\leftmargin \advance\labelwidth -\labelsep \parsep 4pt plus 2pt minus 1pt \let\makelabel\@intrinsiclabel}#1\endlist} \long\def\@intrinsicpar#1#2\\{#1{#2}\@ifstar{\@intrinsictest}{\endlist\endgroup}} \def\@intrinsiclabel#1{\setbox0=\hbox{\rm #1}\ifnum\wd0>\labelwidth \box0 \else \hbox to \labelwidth{\box0\hfill}\fi} \def\Case(#1):{\item[{\it Case (#1):}]} \def\ {\@ifnextchar({\def\@tempq{#1}\@intrinsicopt}{\item[#1]}} \def\@intrinsicopt(#1){\item[{\@tempq} (#1)]} \def\MATRIX#1{\relax \@ifnextchar,{\@MATRIXTABS{}#1,\@FOO, \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar;{\@MATRIXTABS{}#1,\@FOO; \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar:{\@MATRIXTABS{}#1,\@FOO: \hskip0pt plus 1filll\penalty-1\@gobble }{\@ifnextchar.{\hfill\penalty1\null\penalty10000\hskip0pt plus 1filll \@MATRIXTABS{}#1,\@FOO.\penalty-50\@gobble }{\@MATRIXTABS{}#1,\@FOO{ }\hskip0pt plus 1filll\penalty-1}}}}} \def\@MATRIXTABS#1#2,{\@ifnextchar\@FOO{\@MATRIX{#1#2}}{\@MATRIXTABS{#1#2&}}} \def\@MATRIX#1\@FOO{\(\left[\begin{array}{rrrrrrrrrr}#1\end{array}\right]\)} \def\@IFSPACEORRETURNNEXT#1#2{\def\@tempa{#1}\def\@tempb{#2}\futurelet\@ tempc\@ifspnx} { \FUNNYCHARACTIVE \GLOBAL\DEF\FUNNYCHARDEF{\RELAX \DEFa{{\IT\CHAR"61}}\DEFb{{\IT\CHAR"62}}\DEFc{{\IT\CHAR"63}}\RELAX \DEFd{{\IT\CHAR"64}}\DEFe{{\IT\CHAR"65}}\DEFf{{\IT\CHAR"66}}\RELAX \DEFg{{\IT\CHAR"67}}\DEFh{{\IT\CHAR"68}}\DEFi{{\IT\CHAR"69}}\RELAX \DEFj{{\IT\CHAR"6A}}\DEFk{{\IT\CHAR"6B}}\DEFl{{\IT\CHAR"6C}}\RELAX \DEFm{{\IT\CHAR"6D}}\DEFn{{\IT\CHAR"6E}}\DEFo{{\IT\CHAR"6F}}\RELAX \DEFp{{\IT\CHAR"70}}\DEFq{{\IT\CHAR"71}}\DEFr{{\IT\CHAR"72}}\RELAX \DEFs{{\IT\CHAR"73}}\DEFt{{\IT\CHAR"74}}\DEFu{{\IT\CHAR"75}}\RELAX \DEFv{{\IT\CHAR"76}}\DEFw{{\IT\CHAR"77}}\DEFx{{\IT\CHAR"78}}\RELAX \DEFy{{\IT\CHAR"79}}\DEFz{{\IT\CHAR"7A}}\DEF[{{\RM\CHAR"5B}}\RELAX \DEF]{{\RM\CHAR"5D}}\DEF-{\@IFSPACEORRETURNNEXT{{\CHAR"2D}}{{\IT\CHAR"2D}}}} } %%% Warning! Devious return-character machinations in the next several lines! %%% Don't even *breathe* on these macros! {\RETURNACTIVE\global\def\RETURNDEF{\def {\@ifnextchar\FNB{}{\@stopline\@ifnextchar {\@NEWBNFRULE}{\penalty\@M\@startline\ignorespaces}}}}\global\def\@NEWBNFRULE {\vskip\bnfsep\@startline\ignorespaces}\global\def\@ifspnx{\ifx\@tempc\@ sptoken \let\@tempd\@tempa \else \ifx\@tempc \let\@tempd\@tempa \else \let\@tempd\@tempb \fi\fi \@tempd}} %%% End of bizarro return-character machinations. \def\IS{\@stopfield\global\setbox\@curfield\hbox\bgroup \hskip-\bnfindent \hskip-\bnfopwidth \hskip-\bnfalign \hbox to \bnfalign{\unhbox\@curfield\hfill}\hbox to \bnfopwidth{\bf is \hfill}} \def\OR{\@stopfield\global\setbox\@curfield\hbox\bgroup \hskip-\bnfindent \hskip-\bnfopwidth \hbox to \bnfopwidth{\bf or \hfill}} \def\R#1 {\hbox to 0pt{\hskip-\bnfmargin R#1\hfill}} \def\XBNF{\FUNNYCHARDEF\FUNNYCHARACTIVE\RETURNDEF\RETURNACTIVE \def\@underbarchar{{\char"5F}}\tt\frenchspacing \advance\@totalleftmargin\bnfmargin \tabbing \hskip\bnfalign\hskip\bnfopwidth\hskip\bnfindent\=\kill\>\+\@gobblecr} \def\endXBNF{\-\endtabbing} \def\BNF{\BEGIN{XBNF}} \def\FNB{\END{XBNF}} \begingroup \catcode `|=0 \catcode`\\=12 |gdef|@XCODE#1\EDOC{#1|endtrivlist|end{tt}} |endgroup \def\CODE{\begin{tt}\advance\@totalleftmargin\codemargin \@verbatim \def\@underbarchar{{\char"5F}}\frenchspacing \@vobeyspaces \@XCODE} \def\ICODE{\begin{tt}\advance\@totalleftmargin\codemargin \@verbatim \def\@underbarchar{{\char"5F}}\frenchspacing \@vobeyspaces \FUNNYCHARDEF\FUNNYCHARACTIVE \UNDERBARACTIVE\UNDERBARDEF \@XCODE} \def\@underbarsub#1{{\ifmmode _{#1}\else {$_{#1}$}\fi}} \let\@underbarchar\_ \def\@underbar{\let\@tempq\@underbarsub\if\@tempz A\let\@tempq\@underbarchar\fi \if\@tempz B\let\@tempq\@underbarchar\fi\if\@tempz C\let\@tempq\@underbarchar\fi \if\@tempz D\let\@tempq\@underbarchar\fi\if\@tempz E\let\@tempq\@underbarchar\fi \if\@tempz F\let\@tempq\@underbarchar\fi\if\@tempz G\let\@tempq\@underbarchar\fi \if\@tempz H\let\@tempq\@underbarchar\fi\if\@tempz I\let\@tempq\@underbarchar\fi \if\@tempz J\let\@tempq\@underbarchar\fi\if\@tempz K\let\@tempq\@underbarchar\fi \if\@tempz L\let\@tempq\@underbarchar\fi\if\@tempz M\let\@tempq\@underbarchar\fi \if\@tempz N\let\@tempq\@underbarchar\fi\if\@tempz O\let\@tempq\@underbarchar\fi \if\@tempz P\let\@tempq\@underbarchar\fi\if\@tempz Q\let\@tempq\@underbarchar\fi \if\@tempz R\let\@tempq\@underbarchar\fi\if\@tempz S\let\@tempq\@underbarchar\fi \if\@tempz T\let\@tempq\@underbarchar\fi\if\@tempz U\let\@tempq\@underbarchar\fi \if\@tempz V\let\@tempq\@underbarchar\fi\if\@tempz W\let\@tempq\@underbarchar\fi \if\@tempz X\let\@tempq\@underbarchar\fi\if\@tempz Y\let\@tempq\@underbarchar\fi \if\@tempz Z\let\@tempq\@underbarchar\fi\@tempq} \def\@under{\futurelet\@tempz\@underbar} \def\UNDERBARACTIVE{\CATCODE`\_=13} \UNDERBARACTIVE \def\UNDERBARDEF{\def_{\protect\@under}} \UNDERBARDEF \catcode`\$=11 %the following line would allow derived-type component references %FOO%BAR in running text, but not allow LaTeX comments %without this line, write FOO\%BAR %\catcode`\%=11 \makeatother %end of file syntax-macros.tex \title{High Performance Fortran \\ Language Specification} \author{High Performance Fortran Forum} %\date{ } \hyphenation{RE-DIS-TRIB-UT-ABLE sub-script Wil-liam-son} \begin{document} \maketitle \newpage \pagenumbering{roman} \vspace*{4.5in} This is the result of a LaTeX run of a draft of a single chapter of the HPFF Final Report document. \vspace*{3.0in} \copyright 1992 Rice University, Houston Texas. Permission to copy without fee all or part of this material is granted, provided the Rice University copyright notice and the title of this document appear, and notice is given that copying is by permission of Rice University. \tableofcontents \newpage \pagenumbering{arabic} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %put text of chapter here %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %put \end{document} here % Edits by RSS Dec 1, MEZ Dec. 3. %sequence.tex %Version of Dec. 3, 1992 - R. Swift, MasPar Computer Corporation, R. %Schreiber, RIACS, and K. Kennedy, Rice University, % M. Zosel, LLNL, M Hoffert, HP. \chapter{Sequence and Storage Association\protect\footnote{Version of Dec. 3, 1992 - R. Swift, MasPar Computer Corporation, R. Schreiber, RIACS, and K. Kennedy, Rice University, M. Zosel, LLNL, M. Hoffert, HP.}} \label{sequence} \section{Overview} High Performance Fortran (HPF) allows the mapping of variables across multiple processors in order to improve parallel performance. FORTRAN 77 and Fortran 90 both specify relationships between the storage for data objects associated through COMMON and EQUIVALENCE statements, and the order of array elements during association at procedure boundaries between actual arguments and dummy arguments. Otherwise, the location of data is not constrained by the language. COMMON and EQUIVALENCE statements constrain the alignment of different data items based on the underlying model of storage units and storage sequences: \begin{quotation} {\em Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units.} --- ISO/IEC 1539:1991 (E) section 14.6.3.1. \end{quotation} The model of storage association is a single linearly addressed memory, based on the traditional single address space, single memory unit architecture. This model can cause severe inefficiencies on architectures where storage for variables is mapped. Sequence association refers to the order of array elements that Fortran requires when an array expression or array element is associated with a dummy array argument: \begin{quotation} {\em The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, ...} --- ISO/IEC 1539:1991 (E) section 12.4.1.4. \end{quotation} As with storage association, sequence association is a natural concept only in systems with a linearly addressed memory. As an aid to porting FORTRAN 77 codes, HPF allows codes that rely on sequence and storage association to be valid in HPF. Some modification to existing FORTRAN 77 codes may nevertheless be necessary. This chapter explains the relationship between HPF data mapping and sequence and storage association. \section{Storage Association} \subsection{Definitions} \label{sequence-defs} \begin{enumerate} \item COMMON blocks are either {\it sequential} or {\it nonsequential}, as determined by either explicit directive or compiler default. A sequential COMMON block has a single common block storage sequence (5.5.2.1). \item An {\it aggregate variable group} is a collection of variables whose individual storage sequences are parts of a single storage sequence. Variables associated by EQUIVALENCE statements or by a combination of EQUIVALENCE and COMMON statements form an aggregate variable group. The variables of a sequential COMMON block form a single aggregate variable group. \item The {\it size} of an aggregate variable group is the number of storage units in the group's storage sequence (14.6.3.1). \item If there is a member in an aggregate variable group whose storage sequence is totally associated (14.6.3.3) with the storage sequence of the aggregate variable group, that variable is called an {\it aggregate cover}. \item \label{seq-var} Variables are either {\it sequential} or {\it nonsequential}. A variable is {\it sequential} if and only if any of the following holds: \begin{enumerate} \item it appears in a sequential COMMON block; \item it is a member of an aggregate variable group; \item it is an assumed-size array; \item it is a component of a derived type with the Fortran 90 SEQUENCE attribute; \item it is declared to be sequential in an HPF SEQUENCE directive. \end{enumerate} A sequential variable can be storage associated or sequence associated; nonsequential variables cannot. \item A COMMON block contains a sequence of {\it components}. Each component is either an aggregate variable group, or a variable that is not a member of any aggregate variable group. Sequential COMMON blocks contain a single component. Nonsequential COMMON blocks may contain several components that may be nonsequential or sequential variables or aggregate variable groups. \item A variable is {\it explicitly mapped} if it appears in an HPF alignment or distribution directive within the scoping unit in which it is declared; otherwise it is {\it implicitly mapped}. \end{enumerate} \subsection{Examples of Definitions} \CODE IMPLICIT REAL (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150), Z(200) !Example 1: EQUIVALENCE ( A(1), Z(1) ) !Four components: (A, B), C, D, E !Sizes are: 200, 100, 100, 100 !Example 2: EQUIVALENCE ( B(100), Y(1) ) !Three components A, (B, C, D), E !Sizes are: 100, 300, 100 !Example 3: EQUIVALENCE ( E(1), Y(1) ) !Five components: A, B, C, D, E !Sizes are: 100, 100, 100, 100, 150 !Example 4: EQUIVALENCE ( A(51), X(1) ) ( B(100), Y(1) ) !Two components (A, B, C, D), E !Sizes are: 400, 100 !Example 5: EQUIVALENCE ( A(51), X(1) ) ( C(80), Y(1) ) !Two components: (A, B), (C, D, E) !Sizes are: 200, 300 !Example 6: EQUIVALENCE (Y(100), Z(1)) ! One aggregate variable group (Y, Z), not involving the COMMON block. ! Size is 299 !Example 7: !HPF$ SEQUENCE /FOO/ ! The COMMON has one component, the AVG consisting of A, B, C, D, and E ! Size is 500 \EDOC % % EQUIVALENCE ( A(1), Y(1) ) ( B(1), Y(51) ) % !An invalid EQUIVALENCE \noindent In Examples 1--6, common block /FOO/ is nonsequential. Aggregate variable groups are shown as components in parenthesess. Aggregate covers are Z in Example 1 and Y in Example 3. \subsection {Storage Association Directives} A SEQUENCE directive is defined to allow a user to declare explicitly that a variable or a COMMON block is to be treated by the compiler as sequential. (COMMON blocks are by default nonsequential. Variables are nonsequential unless Definition 5 applies.) \BNF storage-association-directive \IS SEQUENCE [[::] association-name-list] association-name \IS variable-name \OR / common-block-name / \FNB \subsection {Storage Association Rules} \begin{enumerate} \item A {\it storage-association-directive} with an empty {\it association-name-list} is treated as if it contained the name of all {\it association-name}s in the scoping unit. \item An aggregate cover may be explicitly mapped. If more than one aggregate cover exists for the aggregate variable group, only one may be explicitly mapped. \item The only sequential variables that may be explicitly mapped are scalar or rank-one variables. Multi-dimensional sequential variables may not be explicitly mapped. \item No explicit mapping may be given for an assumed-size dummy argument array. \item No explicit mapping may be given for a component of a derived-data type having the SEQUENCE attribute. \item If a COMMON block is nonsequential, then all of the following must hold: \begin{enumerate} \item every occurrence of the COMMON block has exactly the same number of components with each corresponding component having a storage sequence of exactly the same size; \item if a component is a nonsequential variable in {\it any} occurrence of the COMMON block, then it must be nonsequential with identical type, shape, and mapping attributes in {\it every} occurrence of the COMMON block; \item if a component is sequential and explicitly mapped (either a variable or an aggregate variable group with an explicitly mapped aggregate cover) in any occurrence of the COMMON block, then it must be sequential and explicitly mapped with identical and mapping attributes in {\it every} occurrence of the COMMON block. In addition, the type and shape of the explicitly mapped variable must be identical in all occurrences. \end{enumerate} \item The result variable of an array-valued function that is not an intrinsic function is a nonsequential array. It may not appear in any HPF SEQUENCE directive. \end{enumerate} \subsection{Storage Association Discussion} Under these rules, variables in a COMMON block can be mapped as long as the components of the COMMON block are the same in every scoping unit that declares the COMMON block. Rule 2 also allows variables involved in an EQUIVALENCE statement to be mapped by the mechanism of declaring a rank-one array to cover exactly the aggregate variable group and mapping that array. As the examples below illustrate, there are many ways to use EQUIVALENCE with COMMON blocks that impact mappability of the variables in subtle ways. In order to allow maximum optimization for performance, the default for variables is to consider them mappable. In order to get correct separate compilation for scoping units that use COMMON blocks with different aggregate variable groups in different scoping units, it will be necessary to insert the HPF SEQUENCE directive. This is an example of where a correct FORTRAN 77 or Fortran 90 program will not necessarily be correct, without modification, in HPF. In order to protect the user and to facilitate portability of older codes, two implementation options are strongly recommended. First, every implementation should supply some mechanism to verify that the type and shape of every mappable array and the sizes of aggregate variable groups in a COMMON are the same in every scoping unit if the COMMON is not declared to be sequential. This same check should also verify that identical mappings have been selected for the variables in COMMON. Implementations without interprocedural information can use a link-time check. The second implementation option recommended is a global mechanism to declare that all COMMON blocks for a given compilation should be considered sequential unless declared otherwise. The purpose of this feature is to permit compilation of large old libraries or subprograms where storage association is known to exist without requiring that the code be modified to apply the HPF SEQUENCE directive to every COMMON block. Since an HPF program is nonconforming if it specifies any mapping that would cause storage units to be mapped onto more than one abstract processor, this puts a constraint on the sequential variables and aggregate covers that can be mapped. In particular, programs that direct double precision or complex arrays to be mapped such that their individual numeric storage inits are split because of some EQUIVALENCE statement or COMMON block layout, are nonconforming. \subsection{Examples of Storage Association} \CODE IMPLICIT REAL (A-Z) COMMON /FOO/ A(100), B(100), C(100), D(100), E(100) DIMENSION X(100), Y(150), Z(200), ZZ(300) EQUIVALENCE ( A(1), Y(1) ) !Aggregate variable group is not mappable. !Sizes are 200, 100, 100, 100. EQUIVALENCE ( B(100), Y(1) ), ( B(1), ZZ(1) ) !Aggregate variable group is mappable only by mapping ZZ. !ZZ is an aggregate cover for B, C, D, and Y. !Sizes are 100, 300, 100. EQUIVALENCE ( E(1), Y(1) ) !Aggregate variable group is mappable by mapping Y. !Sizes are 100, 100, 100, 100, 150. COMMON /TWO/ A(20, 40), E(10,10), G(10,100,1000), H(100), P(100) REAL COVER(200) EQUIVALENCE (COVER(1), H(1)) !HPF$ SEQUENCE A !HPF$ ALIGN E ... !HPF$ DISTRIBUTE COVER (CYCLIC(2)) \EDOC \noindent Here A is sequential and implicitly mapped, E is explicitly mapped, G is implicitly mapped, the aggregate cover of the aggregate variable group (H, P) is explicitly mapped. /TWO/ is a nonsequential COMMON block. In another subprogram, the following declarations may occur: \CODE COMMON /TWO/ A(800), E(10,10), G(10,100,1000), Z(200) !HPF$ SEQUENCE A, Z !HPF$ ALIGN E ... !HPF$ DISTRIBUTE Z (CYCLIC(2)) \EDOC \noindent There are four components of the same size in both occurrences. Components one and four are sequential. Components two and four are explicitly mapped, with the same type, shape and mapping attributes. The first component, A, must be declared sequential in both occurrences because its shape is different. It may not be explicitly mapped in either because it is not rank-one or scalar in the first. E and G must agree in type and shape. E must have the same explicit mapping and G must have no explicit mapping in both occurrences, since they are nonsequential variables. The fourth component must have the same explicit mapping in both occurrences, and must be made sequential explicitly in the second. \section{Argument Passing and Sequence Association} For actual arguments in a procedure call, Fortran 90 allows an array element (scalar) to be associated with a dummy argument that is an array. It furthermore allows the rank of a dummy argument to differ from the rank of the corresponding actual array argument, in effect reshaping the actual via the subroutine call. Storage sequence properties of Fortran are used to identify the values of the dummy argument. This feature, carried over from Fortran 77, has been widely used to pass starting addresses of subarrays, rows or columns of a larger array to procedures. For HPF arrays that are potentially mapped across processors, this feature is not fully supported. \subsection{Sequence Association Rules} \begin{enumerate} \item When an array element or the name of an assumed-size array is used as an actual argument, the associated dummy argument must be a scalar or a sequential array. An array-element designator of a nonsequential array may not be associated with a dummy array argument. \item When an actual argument is an array and the corresponding dummy argument differs from the actual argument in shape, then the dummy argument must be declared sequential and the actual argument must be an entire, sequential array. \item A variable of type character (scalar or array) is nonsequential if it conforms to the requirements of Definition~\ref{seq-var} of Section~\ref{sequence-defs}. If the length of an explicit-length character dummy argument differs from the length of the actual argument, then both the actual and dummy arguments must be sequential. \end{enumerate} \subsection{Discussion of Sequence Association} Correct Fortran 77 (and hence Fortran 90) codes might require modification in HPF. Explicit HPF SEQUENCE directives may be needed in some cases where sequence association exists in order for arrays to be mappable. When the rank of the dummy argument and its associated actual argument differ, the actual argument must not be an expression. There is no HPF mechanism for declaring that the value of an array-valued expression is sequential. In order to associate such an expression as an actual argument with a dummy argument of different rank, the actual argument must first be assigned to a named array variable that is forced to be sequential according to Definition~\ref{seq-var} of Section~\ref{sequence-defs}. The ideal method for porting such codes will be to use an array section as the actual argument, which will allow both the dummy argument and its associated actual argument to be mappable. Examples: Given \CODE SUBROUTINE HOME (X) DIMENSION X (20,10) \EDOC By rule 1 \CODE CALL HOME (ET (2,1)) \EDOC is legal only if X is declared sequential in HOME and ET is sequential in the calling routine. Likewise, by rule 2 \CODE CALL HOME (ET) \EDOC requires either that ET and X are both sequential arrays or that ET is dimensioned exactly as X. There is a special consideration for variables of type character. Change of the length of character variables across a call, as in \CODE CHARACTER (LEN=100) one_long_word CALL webster ( one_long_word ) SUBROUTINE webster( short_dictionary ) CHARACTER (LEN=5) short_dictionary ( 20 ) \EDOC \noindent is conceptually legal in Fortran 77 and Fortran 90. It is allowed provided both actual argument and dummy argument are sequential. This may mean that !HPF$ SEQUENCE directives are needed. \end{document} From abb01.dnet!na@abb-sc.com Sat Dec 5 13:26:32 1992 Received: from netcomsv.netcom.com by titan.cs.rice.edu (AA25814); Sat, 5 Dec 92 13:26:32 CST Received: from abb01.dnet by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA10937; Sat, 5 Dec 92 11:26:16 PST Message-Id: <9212051926.AA10937@netcomsv.netcom.com> Date: Sat, 5 Dec 92 11:08:29 -0800 From: abb01.dnet!na@abb-sc.com (N ARUNASALAM) To: "hpff-f90@cs.rice.edu"@abbsc.dnet Cc: NA@netcom.com Subject: HPFF-F90 and Conditional Compilation Going through both the Metcalf F90 book as well as the HPPF Draft, I find that there is no mention of Conditional Compilation. I recognize that conditional compilation is peripheral to high performance computing issues. However, as HPF may well be the de facto Fortran standard of the 90s and beyond, I'd appreciate it if the discussers would consider the possibility of including this feature in HPF. In the industrial software environment that I am from, conditional compilation is vital to efficient software maintenance. We could get by having separate source files for different platforms and for different projects. But this would create a "multiple maintenance" headache. At present we get by using the GNU-C preprocessor. This is not always very convenient and there is no guarantee that it'll work for all types of FORTRAN programs. Programmers in the academic community may not feel as great a need for conditional compilation as those of us in the industrial community. However, even in the academic world, conditional compilation will be of benefit to those who wish to port their software to many different types of hardware and software platforms (I am assuming that even with POSIX, 100% portability will remain an elusive goal). Thanks for your consideration. N "Aru" Arunasalam e-mail: na@abb-sc.com ABB Systems Control Inc., 2550 Walsh Road, Santa Clara, CA 95051 From knighten@ssd.intel.com Sat Dec 5 14:13:31 1992 Received: from SSD.intel.com by titan.cs.rice.edu (AA25984); Sat, 5 Dec 92 14:13:31 CST Received: by SSD.intel.com (4.1/SMI-4.1) id AA20568; Sat, 5 Dec 92 12:13:24 PST Date: Sat, 5 Dec 92 12:13:24 PST Message-Id: <9212052013.AA20568@SSD.intel.com> From: Bob Knighten Sender: knighten@ssd.intel.com To: na@abb-sc.com Cc: hpff-f90@cs.rice.edu Subject: Re: HPFF-F90 and Conditional Compilation In-Reply-To: <9212051926.AA10937@netcomsv.netcom.com> References: <9212051926.AA10937@netcomsv.netcom.com> Reply-To: knighten@ssd.intel.com (Bob Knighten) Conditional compilation is not included in any programming language standard because it necessarily transcends language issues. The very existence of a compiler is not part of the definition of a programming language, and specifying the mannner in which the compilation is to depend on some aspects of an environment that cannot be part of the language is a hopeless task. For example if HPF were to assume that programs were always compiled as part of a POSIX environment, the specification might require that certain parts of the source be compiled depending on the state of certain environment variables. But even this is neither possible (as POSIX is certainly not a requirement for HPF) nor even sufficient for good conditional compilation on a POSIX system. After a substantial debate INCLUDE became part of Fortran 90, but it is not actually of much value for portability because of the impossibility of a portable specification of what is to be included. Conditional compilation is an even more extreme version of this same kind of problem. There is some hope however. It is likely that vendors will provide extensions to the structured comment mechanism that is a basic part of HPF and this will provide at least a limited conditional compilation facility. Robert L. Knighten | knighten@ssd.intel.com Intel Supercomputer Systems Division | 15201 N.W. Greenbrier Pkwy. | (503) 629-4315 Beaverton, Oregon 97006 | (503) 629-9147 [FAX] From hjr@think.com Sat Dec 5 14:50:17 1992 Received: from mail.think.com by titan.cs.rice.edu (AA26196); Sat, 5 Dec 92 14:50:17 CST Received: from Magenta.Think.COM by mail.think.com; Sat, 5 Dec 92 15:50:16 -0500 From: Harvey Richardson Received: by magenta.think.com (4.1/Think-1.2) id AA28430; Sat, 5 Dec 92 15:50:14 EST Date: Sat, 5 Dec 92 15:50:14 EST Message-Id: <9212052050.AA28430@magenta.think.com> To: knighten@ssd.intel.com Subject: Re: HPFF-F90 and Conditional Compilation Cc: hpff-f90@cs.rice.edu, hjr@think.com > Conditional compilation is not included in any programming language standard > because it necessarily transcends language issues. The very existence of a > compiler is not part of the definition of a programming language, and > specifying the mannner in which the compilation is to depend on some aspects > of an environment that cannot be part of the language is a hopeless task. As you say there is a difference between conditional compilation defined as part of a language standard and a standardisation of a programming environment which can conditionaly provide source lines for compilation. However did not the ANSI C comittee take the latter course and define the behaviour of the C preprocessor? From what I remember there was an approach to the F90 commitee to ask for the ANSI definition of cpp to be included, they voted against it on that basis that it was outside their scope. Perhaps someone can remember exactly what happened. Harvey Richardson Customer Support Group Thinking Machines Corporation From knighten@ssd.intel.com Sun Dec 6 14:14:42 1992 Received: from SSD.intel.com by titan.cs.rice.edu (AA07496); Sun, 6 Dec 92 14:14:42 CST Received: by SSD.intel.com (4.1/SMI-4.1) id AA07774; Sun, 6 Dec 92 12:14:38 PST Date: Sun, 6 Dec 92 12:14:38 PST Message-Id: <9212062014.AA07774@SSD.intel.com> From: Bob Knighten Sender: knighten@ssd.intel.com To: hjr@think.com Cc: hpff-f90@cs.rice.edu Subject: Re: HPFF-F90 and Conditional Compilation In-Reply-To: <9212052050.AA28430@magenta.think.com> References: <9212052050.AA28430@magenta.think.com> Reply-To: knighten@ssd.intel.com (Bob Knighten) Harvey Richardson writes: > . . . > > As you say there is a difference between conditional compilation defined as > part of a language standard and a standardisation of a programming > environment which can conditionaly provide source lines for compilation. > > However did not the ANSI C comittee take the latter course and define the > behaviour of the C preprocessor? > Yes and no. ANSI C certainly defines the linguistic aspects of the C preprocessor, but not its interaction with the programming environment. The conditional compilation features of C are useful primarily when various preprocesor constants can be defined in the external environment or on the command line of the compiler. This is what is not specified. The specification of #include similiarly does not specify the form of file names exactly because that cannot be part of the language specification. So, there are many ways to get conditional compilation including the hack of expecting compilers to ignore code that is part of an IF clause that can be recognized at compile time to never be take, but none of these provides a standard, portable way of specifying conditional compilation. -- Bob Robert L. Knighten | knighten@ssd.intel.com Intel Supercomputer Systems Division | 15201 N.W. Greenbrier Pkwy. | (503) 629-4315 Beaverton, Oregon 97006 | (503) 629-9147 [FAX] From abb01.dnet!na@abb-sc.com Mon Dec 7 20:53:02 1992 Received: from netcomsv.netcom.com by cs.rice.edu (AA10915); Mon, 7 Dec 92 20:53:02 CST Received: from abb01.dnet by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA26134; Mon, 7 Dec 92 18:52:31 PST Message-Id: <9212080252.AA26134@netcomsv.netcom.com> Date: Mon, 7 Dec 92 18:40:57 -0800 From: abb01.dnet!na@abb-sc.com (N ARUNASALAM) To: "hpff-f90@cs.rice.edu"@abbsc.dnet Cc: NA@netcom.com Subject: Re: Conditional Compilation.. (response to comments from Robert L. Knighten) >After a substantial debate INCLUDE became part of Fortran 90, but it is not >actually of much value for portability because of the impossibility of a >portable specification of what is to be included. I agree that INCLUDE by itself doesn't contribute to portability. Together with conditional compilation, however, it can be used quite effectively across different platforms and project environments. (response to Robert K's response to Harvey R's response) >ANSI C certainly defines the linguistic aspects of the C >preprocessor, but not its interaction with the programming environment. >The conditional compilation features of C are useful primarily when various >preprocesor constants can be defined in the external environment or on the >command line of the compiler. This is what is not specified. Typically we define just one project specific name via the command line. This definition is then used in a subsystem-wide "options definition file". So the non-portability of the command line definition is a minor inconvenience... compared to the improvements we gain in software maintainability. (response to Mary Zosel' comments) >I can bring the topic up in the HPF F-90 subgroup meeting this week - >but without a very simple, concrete proposal I can't hold out much >hope. (I suppose one simple - relatively concrete - proposal would >be that each vendor should make cpp work with their HPF - but that >might be quite controversial.) Regarding the CPP proposal, perhaps some vendors will see this as an opportunity for product differentiation. My wishlist for conditional compilation would include the following minimal set: %define name %undefine name %include filename %if-defined name %if-not-defined name } not quite the minimal set! %else-if-defined name } " %else %end-if The pre-processor should support nested conditional compilation statements... I hopes this helps in defining something simple and concrete. N "Aru" Arunasalam e-mail: na@abb-sc.com ABB Systems Control Inc., 2550 Walsh Road, Santa Clara, CA 95051 From @ricevm1.rice.edu:LJM@SLACVM.BITNET Tue Dec 15 11:54:21 1992 Received: from ricevm1.rice.edu by titan.cs.rice.edu (AA11900); Tue, 15 Dec 92 11:54:21 CST Message-Id: <9212151754.AA11900@titan.cs.rice.edu> Received: from RICEVM1.RICE.EDU by ricevm1.rice.edu (IBM VM SMTP V2R2) with BSMTP id 9083; Tue, 15 Dec 92 11:53:59 CST Received: from SLACVM.SLAC.STANFORD.EDU by RICEVM1.RICE.EDU (Mailer R2.08 R208004) with BSMTP id 3686; Tue, 15 Dec 92 11:53:59 CST Received: by SLACVM (Mailer R2.08 R208004) id 2001; Tue, 15 Dec 92 09:53:52 PST Date: Tue, 15 Dec 1992 09:53 -0800 (PST) From: "Len Moss" To: "High Performance Fortran - Fortran 90 Mai" Cc: "Jeanne Martin" Subject: Re: Conditional Compilation.. In-Reply-To: abb01.dnet!na@abb-sc.com -- 12/07/92 18:54 >[stuff omitted] > >(response to Mary Zosel' comments) > >>I can bring the topic up in the HPF F-90 subgroup meeting this week - >>but without a very simple, concrete proposal I can't hold out much >>hope. (I suppose one simple - relatively concrete - proposal would >>be that each vendor should make cpp work with their HPF - but that >>might be quite controversial.) > >Regarding the CPP proposal, perhaps some vendors will see this as an >opportunity for product differentiation. My wishlist for conditional >compilation would include the following minimal set: > >%define name >%undefine name >%include filename >%if-defined name >%if-not-defined name } not quite the minimal set! >%else-if-defined name } " >%else >%end-if > >The pre-processor should support nested conditional compilation >statements... >I hopes this helps in defining something simple and concrete. > >N "Aru" Arunasalam e-mail: na@abb-sc.com >ABB Systems Control Inc., >2550 Walsh Road, >Santa Clara, CA 95051 Jeanne Martin (a member of X3J3 and convernor of its ISO counterpart, WG5) has done some work on a concrete proposal for a standard Fortran preprocessor, which is quite a bit more "Fortran-like" than CPP. The most recent draft that I'm aware of is from July, 1990 and can be found in the WG5 distribution (ISO/IEC JTC1/SC22/WG5 N539). With Jeanne's permission, I'd be happy to mail paper copies to anyone interested (sorry, I don't have an electronic copy -- but perhaps Jeanne will contribute one?). PS: I just talked to Jeanne and she said she'd see if she could find an electronic copy of her preprocessor proposal. She also reminded me that at one point Fortran 8x included a conditional compilation facility, but it was later removed, mainly to reduce the overall size of the language. -- Leonard J. Moss | My views don't necessarily Stanford Linear Accelerator Center, MS 97 | reflect those of SLAC, Stanford, CA 94309 | Stanford or the DOE From martin@ocfmail.ocf.llnl.gov Tue Dec 15 17:08:43 1992 Received: from ocfmail.ocf.llnl.gov by titan.cs.rice.edu (AA22849); Tue, 15 Dec 92 17:08:43 CST Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA23158; Tue, 15 Dec 92 15:08:28 PST Date: Tue, 15 Dec 92 15:08:28 PST From: martin@ocfmail.ocf.llnl.gov (Jeanne Martin) Message-Id: <9212152308.AA23158@ocfmail.ocf.llnl.gov> To: hpff-f90@cs.rice.edu Subject: Fortran Preprocessor Cc: JTM@llnl.gov, LJM@slacvm.slac.stanford.edu Here is the proposal that Len Moss mentioned (minus italic and bold font, but still readable). ____________________________________________________________________________ ISO/IEC JTC1/SC22/WG5 - N539 A Standard Fortran Preprocessor Jeanne Martin July 13, 1990 CONTENTS Is a Fortran preprocessor needed? 1 A Preliminary Proposal 2 Preprocessor Source 2 Preprocessor Variables 3 Conditional Inclusion of Code 4 Macro Definition 4 Macro Expansion 5 Macro Files 6 Preprocessor Intrinsic Functions 6 Relocating Text 8 Summary of Proposed Fortran Preprocessor Features 10 Summary of ANSI C Preprocessor Features 11 Is a Fortran preprocessor needed? What can a preprocessor do for the Fortran programmer? (1) Frequently a programmer needs to maintain more than one version of a code. There may be a need to run the code in different environments; there may be special requirements for some users of the code; or it may be necessary to test an expermimental version without disrupting the original. It is frequently difficult enough to maintain a large code, much less several versions of the code. For the programmer, the best solution is a single source file that can be preprocessed to extract the exact version needed for each special purpose. This strategy has many advantages for the programmer. There is only one source to maintain. If an error is discovered in one version that applies to all versions, it can be rectified only once. There is no chance that it will be overlooked and crop up again. (2) Frequently in a program, there will be a sequence of statements that appear in many places, perhaps with slight modifications. Duplicating the statements and making minute changes is error prone. If an error is discovered in the sequence, every place where the sequence is replicated must be located and rectified. It would be much better to specify the sequence once, designating the places where variations occur. Then the sequence can be inserted, properly adjusted, wherever it is needed. This has the advantage of shortening the source representation of the code and making trivial the correction of an error or the installation of an enhancement in the sequence. What preprocessor features make these advantages possible? There are two basic features: conditional code inclusion and macro definition and expansion. In addition there are two minor features: a mechanism to specify preprocessor variables to phrase the conditions that determine code inclusion and a mechanism to include macro definitions kept in external files. The new Fortran 90 standard does not contain specifications for conditional inclusion of source lines or for macros with arguments. It does specify an include facility. At LLNL, where Fortran preprocessors have been provided as part of the Fortran environment, it has been estimated that 84% of the lines of an important class of applications require some form of preprocessor support for macro expansion, conditional code, or inclusion of code from another source file. Since there is no standard for most of the needed facilities, it will be difficult to move these applications to platforms supported by vendor-supplied software. The C standard specifies conditional inclusion of code and macros with arguments. Generally preprocessing is built into C compilers. There are stand alone C preprocessors but these are heavily tied to C syntax and source form. Although C programmers have come to rely on preprocessor capabilities, there does not appear to be any good Fortran-based equivalent in the Unix community. What appears to be needed is a preprocessor uniquely specified for Fortran, but easy to use and understand. It could provide facilities that C programmers have grown to expect in UNIX environments. Thus there are at least two communities that feel preprocessing is required for programming language support: LLNL Fortran programmers and C programmers. Should WG5 attempt to develop a standard for Fortran preprocessing support? A new product that conformed to such a standard could be built on reusable modules. Some of the same functionality (analyzing Fortran source, evaluating Fortran expressions, creating Fortran output, etc.) is needed for other tools that could further enrich the Fortran environment. A Preliminary Proposal The following proposal is suggested as a starting point for discussion leading to a more formal design. All keywords, syntax, semantics, and rules proposed are subject to change for better ways to meet user requirements. Unresolved issues are flagged by ???. The meta language used to describe the statements and constructs in this section makes use of square brackets ([ ]) to indicate optional elements and ellipses (...) to indicate multiple occurrences of preceding optional elements. Preprocessor Source Preprocessor source should be ordinary Fortran source with interspersed preprocessor statements. A preprocessor statement would begin with a special character. C uses a number sign (#), but this is one of the characters which the SC22 Ad Hoc Group on Character Handling in Programming Languages recommends be avoided (along with $, [, ], and others). In the existing Fortran character set, this leaves only the question mark (?) as an available, as-yet-unused character. So even though it is not ideal, it will be used for illustrative purposes in this preliminary proposal. It is proposed that this chosen character may appear in any character position and must be followed immediately by the text of the preprocessor command; that is, no space is allowed between the ? and the command. Note that Fortran 90 include lines are not preprocessor statements. For scoping purposes, the preprocessor needs to recognize subprogram boundaries; that is, it must parse and record the following Fortran statements and all of their variations: PROGRAM END PROGRAM SUBROUTINE END SUBROUTINE FUNCTION END FUNCTION MODULE END MODULE BLOCK DATA END BLOCK DATA END Design Decision: ???Should a Fortran preprocessor assume source will always be in free form and that the preprocessor output is to be in free form??? Preprocessor Variables Preprocessor variables are needed to specify the conditions in conditional inclusion constructs. In C, a preprocessor variable is treated like a simple macro and uses the same syntax as is used for within-line macros with no arguments. For Fortran, the following is proposed: ?define name string This results in every occurrence of the token name outside of comments, (character contexts and format statements???) being replaced by string (without evaluation). The definitions themselves are not transferred to the output text. The string associated with a given name may change at any time by redefinition. The most recently specified string is the one used for replacement. Inline replacements with arguments are permitted when the general form is implemented: ?define [function] name [( arg [,arg]...)] string-with-args-inserted The keyword function must be present if there are arguments. The argument names (arg) must be recognizable tokens in the string. For example: Preprocessor Source ?DEFINE NEW_VERSION .TRUE. ?DEFINE FUNCTION CONVERT(TO_CELSIUS) (5*(TO_CELSIUS- 32))/9 ... IF (NEW_VERSION) CALL EXTEND TEMP = CONVERT(72) Preprocessor Output IF (.TRUE.) CALL EXTEND TEMP = (5*(72-32))/9 With these preprocessor variables defined, the source is easier to read, and an optimizing compiler produces efficient code. The scope of preprocessor variables is the subprogram in which they are defined (main program, subroutine, function, module, or block data subprogram). A preprocessor variable defined outside any of these scoping units has global scope, and its definition is available inside any of the scoping units in the precompilation unit being processed. This is analogous to Fortran 90 entities that are specified to be global to a module by being defined outside of any module procedures in the module. Conditional Inclusion of Code The proposed conditional inclusion facility ( the ?if construct) is modeled on the Fortran IF construct. ?if (condition1) then block1 [?elseif (condition2) then block2 ] ... [?else blockn ] ?endif No more than one block will appear in the preprocessed text. The preprocessor variables used to determine whether code inclusion takes place are specified by ?define statements, which causes variable names in the conditions to be replaced by strings. The preprocessor must convert these condition strings to appropriate operands and operators and evaluate them to get a true or false result. The preprocessor standard must specify which data types are permitted for operands and which operators are allowed. These might be different from what is currently allowed for Fortran 90 scalar values (???reals excluded?, long character strings allowed?, the concatenation operator allowed?, some of the Fortran 90 intrinsic functions allowed???, etc.). The types of operands and the operators allowed in ?if constructs must be specified in the final design. For example: Preprocessor Source ?DEFINE NEW_VERSION .TRUE. ... ?IF (NEW_VERSION) THEN CALL SUPER_CALC (X, Y, Z) ?ELSE CALL CALC (X, Y, Z) ?ENDIF Preprocessor Output CALL SUPER_CALC (X, Y, Z) Conditional inclusion allows two versions of a program to be maintained within one copy of the source for the program. Macro Definition Macros are similar in purpose to preprocessor variables. They are needed when the replacement text (the macro-body) involves several statements. Macro definitions have the form: ?define macro [function] name {(arg {,arg }... )} macro-body ?end[ ]macro [name] Arguments are treated much as subprogram arguments are treated in Fortran. They are indicated by name on the ?define line. The places where they are replaced in the macro body are signaled by the appearance of the argument name. As with preprocessor variable definitions, macro definitions do not appear in the preprocessor output. For example: ?DEFINE MACRO ADD_ITEM (ITEM) TABLE_SIZE = TABLE_SIZE + 1 IF (TABLE_SIZE <= MAX) THEN TABLE(TABLE_SIZE) = ITEM ELSE CALL ERROR ("TABLE OVERFLOW") STOP END IF ?END MACRO ADD_ITEM This allows frequently repeated code to be specified once. If, at some future time, the error handling should change, it can be adjusted in just this one place. The scope of macros is the subprogram in which they are defined (main program, subroutine, function, module, or block data subprogram). A macro defined outside any of these scoping units has global scope, and its definition is available inside any of the scoping units in the precompilation unit being processed. The macro-body associated with a given name may change at any time. The most recently specified macro-body is the one used for replacement. (See the ?include directive below for the means of incorporating macro definitions from external files.) A formal macro argument name may appear as the argument of the intrinsic preprocessor function ?present, which has the same purpose as the present intrinsic function in Fortran 90. It permits inquiries about the presence of that argument in a particular expansion. If an argument is not present, it may be associated with a default string. Macro Expansion Macro expansions take the form name [(arg-spec [,arg-spec]...)] where arg-spec is one of the following arg-string arg-name = arg-string The second form for arg-spec is identical to the keyword form for subprogram arguments in Fortran 90, and, as in Fortran 90 subprogram invocations when keywords are used, the arguments may appear in any order. Macro bodies may contain macro expansions to any depth. Recursion is allowed. [Note: Recursive expansion is not permitted in C, but this seems unnecessarily restrictive.] A macro expansion may appear on a line by itself. In this case it is analogous to a CALL statement in Fortran except that the expansion line is replaced by the macro body with arguments properly inserted. For example using the macro ADD_ITEM defined above: Preprocessor Source Preprocessor Output ADD_ITEM (X(I,J)) TABLE_SIZE = TABLE_SIZE + 1 IF (TABLE_SIZE <= MAX) THEN TABLE(TABLE_SIZE) = X(I,J) ELSE CALL ERROR ("TABLE OVERFLOW") STOP END IF A macro expansion may appear embedded in preprocessor text. In this case, the define macro line must contain the keyword function and the macro-body must contain at least one reference to the preprocessor intrinsic function ?return. This kind of macro expansion is analogous to a Fortran function invocation. The argument to the ?return intrinsic serves as the replacement text for the macro expansion. For example: Preprocessor Source Preprocessor Output ?DEFINE COUNTRY "UK" ?DEFINE MACRO SIDE ?IF (COUNTRY.EQ."UK") THEN ?RETURN ("LEFT") ?ELSE ?RETURN ("RIGHT") ?ENDIF ?END MACRO SIDE RULE = "KEEP TO "//SIDE RULE = "KEEP TO "//"LEFT" Macro Files It is convenient to collect related macro definitions into files. A mechanism is required to make externally defined macros and possibly other information known to a particular execution of the preprocessor. The following statement is used ?include filename It is similar in function to the Fortran 90 include line. Nested ?includes are permitted. Preprocessor Intrinsic Functions There are occasions when special preprocessor actions are desired. It is convenient to have preprocessor intrinsic functions that perform operations on an argument string and replace the function invocation with the result of the operations. Two of these intrinsic functions have already been mentioned: ?present that permits inquiries about the presence of an argument in a macro expansion and ?return that is used to specify the replacement text for a macro invoked like a Fortran function. A third such function is ?len. When ?len (arg-name) appears in a macro body where arg-name is an argument to the macro, the expansion text will contain an integer that is the number of characters in the actual arg-string. For example, if LIST is a growing character string of terms and NOCHARS is the number of characters put into LIST, then a macro can be defined to add terms to the list and keep track of the ending character position: Preprocessor Source Preprocessor Output ?DEFINE MACRO ADDTERM (TERM) LIST = LIST(1:NOCHARS)//"TERM" NOCHARS = NOCHARS + ?LEN(TERM) ?END MACRO ADDTERM ... CHARACTER (20000) LIST CHARACTER (20000) LIST INTEGER :: NOCHARS=0 INTEGER :: NOCHARS=0 ... ... ADDTERM (BEGIN ) LIST = LIST(1:NOCHARS)//"BEGIN " NOCHARS = NOCHARS + 6 A fourth preprocessor intrinsic function is ?eval. It evaluates expressions with the same allowed operands and operators as are permitted in the ?if construct. For example, the string "?eval(2*10)" would be replaced by the string "20". There are two places where evaluation is necessary in the preprocessor syntax (?if constructs and substring expressions (see below)), and in these places it is handled automatically. There may be other places where programmers might want a string replaced by a different string that represents the evaluated result and in these places they would need ?eval, for example, if it is necessary to generate unique statement labels. The programmer could set aside a range for numeric labels that can be used exclusively by the preprocessor, for example every label above 90000. The programmer could then define a global preprocessor variable ?DEFINE LABEL 90000 Then a label occurrence could appear in any macro definition as follows LABEL CONTINUE ?DEFINE LABEL ?EVAL(LABEL+1) The preprocessor variable LABEL now has the value 90001 and can be used again. A fifth preprocessor intrinsic is ?defined. It could be used to test the definition status of a preprocessor variable or macro. It might be used in the conditional inclusion construct and would return a true or false result. For example: Preprocessor Source ?DEFINE NEW_VERSION .TRUE. ... ?IF (?DEFINED(NEW_VERSION) THEN CALL SUPER_CALC (X, Y, Z) ?ELSE CALL CALC (X, Y, Z) ?ENDIF Preprocessor Output CALL SUPER_CALC (X, Y, Z) An arg-string can be considered as a character string. Fortran 77 provides a substring syntax for character strings of the form string (initial:terminal) such that if string is "abcdefg", then string(2:5) is "bcde" This same functionality could be allowed in a macro body and would permit the selection of a portion of an argument string. It could be specified by a sixth preprocessor intrinsic function ?substring (string-name, initial, terminal). The initial and terminal specifications may be expressions, and , if so, they are evaluated automatically, just as the expressions in the ?if construct are evaluated, only these produce integer results. For example if ARG is the string ABCDE and M has the value 2: Preprocessor Source Preprocessor Output ?SUBSTRING(ARG, ,1) A (first character of arg) ?SUBSTRING(ARG,?LEN(ARG), ) E (last character of arg) ?SUBSTRING(ARG, ,M) AB (first m charac ters of arg) ?SUBSTRING(ARG,?LEN(ARG)-M+1, ) DE (last m characters of arg) Some times it is necessary to generate a unique name for an entity in a macro; for example, a loop index in a recursive expansion. For this purpose a seventh intrinsic ?unique (alias) could be provided. It has one argument that serves as an alias within this macro expansion for the unique name the preprocessor has created. Relocating Text Fortran 77 and Fortran 90 have strict statement ordering rules. They require all declaratives before all executable statements. Sometimes it is convenient to specify declaratives in macros that are expanded after the executable statements begin. For example, take the loop index in a recursively expanded macro. If the program contains an IMPLICIT NONE statement, each new loop index must be explicitly declared and the declarations placed ahead of the executable code. To allow for this the preprocessor could provide a ?divert construct and an ?insert statement. ?divert name statement-stream ?end[ ]divert [name] ?insert name Sequences of statements are given names and any number of named sequences of statements are permitted. The ?divert construct may appear in a macro body to name a sequence of declaratives that need to be relocated. The sequence is cumulative, that is any subsequent statements given the same name will be treated as continuations of the earlier sequence. This is analogous to COMMON and NAMELIST lists in Fortran 90. The ?insert statement may then appear before any executable statements in a Fortran subprogram to indicate the position to which the named stream has been "diverted". For example: File MYFILE ?DEFINE MACRO MYMACRO (Z) ?DIVERT DECLARATIVES REAL ?UNIQUE(I) ?END DIVERT DECLARATIVES CALL CALCULATE (I,Z) Z=I+Q ?END MACRO MYMACRO Preprocessor Source Preprocessor Output SUBROUTINE EXAMPLE SUBROUTINE EXAMPLE ?INCLUDE MYFILE REAL P,Q,R REAL P,Q,R REAL I?0000 ?INSERT DECLARATIVES REAL I?0001 CALL CALCULATE (P,Q) CALL CALCULATE (P,Q) MYMACRO (P) CALL CALCULATE (I?0000,P) MYMACRO (R) P=I?0000+Q END SUBROUTINE EXAMPLE CALL CALCULATE (I?0001,R) R=I?0001+Q END SUBROUTINE EXAMPLE In this case I?0000 and I?0001 are the unique names generated by a hypothetical preprocessor (using a character not permitted in names and a sequence number). This diversion mechanism can be used for statements other than declaratives, but its primary purpose is to get around the rigid statement ordering rules in Fortran. ???An alternative to this mechanism could be an automatic sort of statement types by the preprocessor such that all USE statements were first, followed by IMPLICIT statements, followed by type definition and declaration statements, etc., according to the Fortran rules.??? Summary of Proposed Fortran Preprocessor Features For preprocessor variable definition: ?define [function] name [( arg [,arg]...)] string-with-args-inserted For macro definition: ?define macro [function] name [(arg [,arg ]... )] macro-body-with-args-inserted ?end[ ]macro [name] For conditional code inclusion: ?if (condition1) then block1 [?elseif (condition2) then block2 ] ... [?else blockn ] ?endif For preprocessor variable replacement and macro expansion [text] name [(arg-spec [,arg- spec]...)] [text] where arg-spec is [arg-name =]arg-string For external file inclusion ?include filename For statement relocation ?divert name statement-stream ?end[ ]divert [name] ?insert name Preprocessor intrinsic functions are ?present, ?return, ?len, ?eval, ?substring,?defined, and ?unique. Summary of ANSI C Preprocessor Features For preprocessor variable definition: #define name [( arg [,arg]...)] string-with- args-inserted #undef name For macro definition: #define name [(arg [,arg ]... )] macro-body- with-args-inserted For conditional code inclusion: #if (condition1) block1 [#elif (condition2) block2 ] ... [#else blockn ] #endif #ifdef name block #endif #ifndef name block #endif For preprocessor variable replacement and macro expansion [text] name [(arg-spec [,arg- spec]...)] [text] where arg-spec is arg-string For external file inclusion #include filename For communication to the debugger and compiler #line linenumber [filename] #pragma [token]... #error error-number Preprocessor operators #name paste name ## concatenate defined(name) inquiry intrinsic for definition status of name From chk@erato.cs.rice.edu Tue Jan 26 22:41:40 1993 Received: from erato.cs.rice.edu by titan.cs.rice.edu (AA01848); Tue, 26 Jan 93 22:41:40 CST Received: from localhost.cs.rice.edu by erato.cs.rice.edu (AA08481); Tue, 26 Jan 93 22:41:23 CST Message-Id: <9301270441.AA08481@erato.cs.rice.edu> To: hpff@erato.cs.rice.edu Cc: hpff-core@erato.cs.rice.edu, hpff-distribute@erato.cs.rice.edu, hpff-forall@erato.cs.rice.edu, hpff-io@erato.cs.rice.edu, hpff-f90@erato.cs.rice.edu, hpff-intrinsics@erato.cs.rice.edu Word-Of-The-Day: salariat : (n) the class of salaried workers Subject: HPF Language Specification, version 1.0 Date: Tue, 26 Jan 93 22:41:22 -0600 From: chk@erato.cs.rice.edu It's available! (For sure from titan.cs.rice.edu; availability from other sites will depend on how fast e-mail travels and how dedicated administrators at other sites are.) Below are the "standard" announcement and call for comments. Many thanks to everyone involved in producing this document, including (but not limited to!): The HPFF working group. People who commented on version 0.4 of the spec. People who attended (and asked questions at) many presentations, including the Supercomputing '92 workshop. Our friendly funding agencies: DARPA, NSF, ESPRIT, and the employers who bankrolled most of the HPFF committee members. Special thanks to David Loveman, who edited the document. Chuck Koelbel Executive Director, NSF ---------------------------------------------------------------- The most recent draft of the High Performance Fortran Language Specification is version 1.0 Darft, dated January 25, 1993. See "Version History" below for a description of the changes. How to Get the High Performance Fortran Language Specification ============================================================== There are three ways to get a copy of the draft: 1. Anonymous FTP: The most recent draft is available on titan.cs.rice.edu in the directory public/HPFF/draft. Several files are kept there, including compressed Postscript files of previous versions of the draft. The most current version of this draft is 0.4, which can be retrieved as a tar file containing LaTeX source (hpf-v10.tar) or in Postscript format (hpf-v10.ps); both of these are also available as compressed files. Several other sites also have the draft available in one or more formats, including think.com, ftp.gmd.de, theory.tc.cornell.edu, and minerva.npac.syr.edu. 2. Electronic mail: The most recent draft is available from the Softlib server at Rice University. This can be accessed in two ways: A. Send electronic mail to softlib@cs.rice.edu with "send hpf-v10.ps" in the message body. The report is sent as a Postscript file. B. Send electronic mail to softlib@cs.rice.edu with "send hpf-v10.tar.Z" in the message body. The report is sent as a uuencodeded compressed tar file containing LaTeX source. C. Send electronic mail to netlib@ornl.gov with "send hpf-v10.ps from hpf" in the message body. The report is sent as a Postscript file. This site also has the LaTeX source of the draft; use "send index from hpf" to see the file names. D. Send electronic mail to netlib@research.att.com with "send hpf-v10.ps from hpff" in the message body. The report is sent as a Postscript file. (In all cases, the reply is sent as several messages to avoid mailer restrictions; edit the message bodies together to obtain the whole file.) The same files can be obtained from David Loveman (loveman@mpsg.enet.dec.com) and Chuck Koelbel (chk@cs.rice.edu), but replies will take longer because real people have to answer the mail. 3. Hardcopy: The most recent draft is available as technical report CRPC-TR 92225 from the Center for Research on Parallel Computation at Rice University. Send requests to Theresa Chatman CITI/CRPC, Box 1892 Rice University Houston, TX 77251 There is a charge of $50.00 for this report to cover copying and mailing costs. Disclaimers =========== A few caveats about the HPF draft: A. The current version contains some material that is still under active discussion. Changes will be fairly frequent until at least December 1992. New versions will be announced on the HPFF mailing list and in the newsgroups comp.parallel, comp.lang.misc, and comp.lang.fortran. B. The HPF Language Specification does not necessarily represent the official view of any individual, company, university, government, or other agency. C. Please address any questions, comments, or possible inconsistencies in the draft to hpff-comments@cs.rice.edu. Include the chapter number you are commenting on in the "Subject:" line of the message. Version History =============== Version 0.1: August 14, 1992 EXTREMELY preliminary version. First collection of the proposals active in the High Performance Fortran Forum. Established much of the outline for later documents, and represented most decisions made through the July HPFF meeting. Version 0.2: September 9, 1992 Version discussed at the September 10-11 HPFF meeting Changes: General cleaning up of version 0.1. Inclusion of most new proposals at that time. Version 0.3: October 12, 1992 Version discussed at the October 22-23 HPFF meeting Changes: Numerous minor and major changes due to discussions at the September meeting. Added a section on "Model of Computation". Presented alternate chapters for data distribution with and without templates. Added two proposals for ON clauses specifying where computation is to be executed. Added distribution inquiry intrinsics. Total rewrite of I/O material, sending most previous material to the Journal of Development. Version 0.4: November 6, 1992 Version to be presented at Supercomputing '92 Changes: Numerous minor and major changes due to discussions at the October meeting. "Acknowledgements" section now much more accurate. "The HPF Model" (replacing "Model of Computation") substantially simplified and improved. "Distribution without Templates" chapter removed. Many proposals not adopted moved to "Journal of Development". Version 1.0: January 25, 1993 Draft final version Changes: Many changes for clarity or pedagogical reasons. The examples in several sections have been significantly enlarged. INHERIT (for dummy arguments) added to distribution chapter. Pure procedures may now have dummy arguments with explicit distributions, if those distributions are inherited from the caller. Changed the names of the new reductions AND, OR, and EOR to IALL, IANY, and IPARITY. Clarified the status of the character array language to be not in the subset, and as a result, removed the character array intrinsics. Only very restricted forms of alignment subscript expressions (of the form \(m*i + n\) where \(m\) and \(n\) are integer expressions) are part of the subset. [Bibliography] Correctly spelled ``Mehrotra'' and ``Gerndt''. ---------------------------------------------------------------- REQUEST FOR PUBLIC COMMENT ON HIGH PERFORMANCE FORTRAN To: The High Performance Computing Community Invitation: The High Performance Fortran Forum (HPFF), with participation from over 40 organizations, has been meeting since January 1992 to discuss and define a set of extensions to Fortran called High Performance Fortran (HPF). Our goal is to address the problems of writing data parallel programs for architectures where the distribution of data impacts performance. While we hope that the HPF extensions become widely available, HPFF is not sanctioned or supported by any official standards organization. At this time, HPFF invites general public review comments on the initial version of the language draft. The HPF language specification, version 1.0 draft, is now available. This document contains all the technical features proposed for the language. We plan to make minor revisions to correct errors or clarify ambiguities in March 1993, at which time we will issue a final draft; however, we expect that there will be few (if any) major technical changes from this draft. HPFF invites comments on the technical content of HPF, as well as on the editorial presentation in the document. To facilitate incorporation of comments into the final document, we ask that comments be sent before March 1, 1993. comments, we ask that How to Get the Documents: Electronic copies of the HPF language specification are available from numerous sources. Anonymous FTP sources: Directory: titan.cs.rice.edu public/HPFF/draft think.com public/HPFF ftp.gmd.de hpf-europe theory.tc.cornell.edu pub minerva.npac.syr.edu public Email sources: First line of message: netlib@research.att.com send hpf-v10.ps from hpff netlib@ornl.gov send hpf-v10.ps from hpf softlib@cs.rice.edu send hpf-v10.ps The following formats are available (xx will be 04 or 10, depending on version). Note that not all formats are available from all sources. hpf-v10.dvi DVI file hpf-v10.ps Postscript hpf-v10.ps.Z Compressed Postscript hpf-v10.tar Tar file of LaTeX version hpf-v10.tar.Z Compressed tar file For more detailed instructions, send email to hpff-info@cs.rice.edu. This will return a message with expanded detail about accessing the above document sources, as well as other information about HPFF. We strongly encourage reviewers to obtain an electronic copy of the document. However, if electronic access is impossible the draft is also available in hard copy form as CRPC Technical Report #92225. This report is available for $50 (copying/handling fee) from: Theresa Chatman CITI/CRPC, Box 1892 Rice University Houston, TX 77251 Make checks payable to Rice University. This document will be sent surface mail unless additional airmail postage is included in the payment. How to Submit Comments: HPFF encourages reviewers to submit comments as soon as possible, with a deadline of February 15 for consideration. Please do not submit comments for any version of the draft earlier than the 0.4 version. Please send comments by email to hpff-comments@cs.rice.edu. To facilitate the processing of comments we request that separate comment messages be submitted for each chapter of the document and that the chapter be clearly identified in the "Subject:" line of the message. Comments about general overall impressions of the HPF document should be labeled as Chapter 1. All comments on the language specification become the property of Rice University. If email access is impossible for comment responses, hard copy may be sent to HPF Comments c/o Theresa Chatman CITI/CRPC, Box 1892 Rice University Houston, TX 77251 HPFF plans to process the feedback received at a meeting in March. Best efforts will be made to reply to comments submitted. Sincerely, Charles Koelbel Rice University HPFF Executive Director