From jwagener@ionet.net Sat May 4 05:52:41 1996 Received: from ion3.ionet.net (ion3.ionet.net [204.96.200.8]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id FAA00453 for ; Sat, 4 May 1996 05:52:37 +0200 Received: from erehwon (tsip116.ionet.net [206.28.164.125]) by ion3.ionet.net (8.6.12/8.6.12) with SMTP id WAA21291; Fri, 3 May 1996 22:52:05 -0500 X-Mailer: InterCon TCP/Connect II 2.2.1 MIME-Version: 1.0 Message-Id: <9605032256.AA04809@erehwon> Date: Fri, 3 May 1996 22:56:04 -0500 From: "Jerrold L. Wagener" To: sc22wg5@dkuug.dk Cc: jwagener@ionet.net Subject: informal JLW report on the May'96 HPFF meeting Content-Type: Multipart/Mixed;boundary=part_ADB03F8400CE66FF00000003 --part_ADB03F8400CE66FF00000003 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline HPFF met May 1-3 in Arlington, TX; this was the next-to-last meeting for defining the content of HPF 2.0. The HPF 2.0 document, which will assume a Fortran 95 base, will be completed at the next meeting (July 10-12, in San Francisco) and made available for public comment. A meeting scheduled for Sept 18-20 will be devoted to resolving the public comments and producing the final document by Supercomputing'96 in Nov. The number of announced HPF 1.0 implementations now stands at 15, with Thinking machines and Fujitsu making announcements since the last meeting. Specific technical features considered at this meeting include sort_up and sort_down library functions, tasking on processor subsets (ON, RESIDENT) and with TASK REGION - END TASK REGION parallel barriers, mapping of pointers, an F77_LOCAL extrinsic interface, and C interoperability; the last of these is of the most direct interest to WG5/X3J3. In addition, a process was adopted to accommodate HPF "plug-ins" supported by organizations other than HPFF. As for C interoperability, HPFF is adamant that something on this be included in the HPF 2.0 document. The WG5 draft technical report (WG5/N1178) was reviewed but not adopted as a replacement for what HPFF had previously approved. It is perhaps unfortunate that the HPFF and WG5 schedules do not appear to allow time for a unified approach to emerge before HPF 2.0 goes to press. If I may call the two approaches M and H (after the principal authors of each), the principal thrust of M is to extend the interface block to accommodate C interfaces and the principal thrust of H is to extend the data types to accommodate C types. M confines its scope pretty much to the interface block and expects the implementation to take care of the data coersions "on the fly"; H defines new type kind parameters for the C types and requires the programmer to manage the data coersions outside of the interface (i.e., before and after the call). M requires relatively more syntax invention; H makes extensive use of the existing type kind mechanism. M interface blocks are more complicated (and show it), but M involves little work outside the interface block; H interface blocks are simpler and cleaner, but H requires much programmer attention (in multiple places) to C things outside the interface block. With the present drafts, M and H appear to be roughly functionally equivalent (and roughly equally deficient), and there doesn't appear to be much difference in implementation costs. In an 18-2-1 straw vote HPFF favored the M approach, the biggest factor (it seemed to me) being M's tendency to localize all the C worry in one place. HPFF is going to attempt to replace/revise the "map_to" feature of M with some form of the type kind techniques of H, keeping the scope local to the interface block. That could be a step toward a unified approach. Jerry --part_ADB03F8400CE66FF00000003 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline ========================================== Jerrold L. Wagener jwagener@ionet.net 6 E 5th, Suite 308 918-592-3023 Tulsa, OK 74103 --part_ADB03F8400CE66FF00000003--