From zongaro@VNET.IBM.COM Tue Aug 20 17:08:50 1996 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id RAA11677 for ; Tue, 20 Aug 1996 17:08:44 +0200 Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6152; Tue, 20 Aug 96 11:08:22 EDT Received: by TOROLAB (XAGENTA 4.0) id 1082; Tue, 20 Aug 1996 11:00:18 -0400 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA23529; Tue, 20 Aug 1996 10:56:07 -0400 From: (Henry Zongaro) Message-Id: <9608201456.AA23529@twinpeaks.torolab.ibm.com> Subject: X3J3 Paper 96-145r1 To: sc22wg5-interop@ncsa.uiuc.edu Date: Tue, 20 Aug 1996 10:56:06 -0400 (EDT) Cc: hennecke@rz.uni-karlsruhe.de, sc22wg5@dkuug.dk X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 4959 Hello, The following paper was passed at X3J3 Meeting 138, last week in Las Vegas. Please have a look at it - X3J3 would like to see some further discussion on the decision made in Dresden to combine the BIND and MAP_TO approaches to interoperability. Thanks, Henry X3J3/96-145r1 Page 1 of 2 Date: 1996/08/14 To: X3J3 From: /io Subject: Dresden Resolution D6 (Interoperability) References: X3J3/96-123 With Dresden Resolution D6, WG5 decided to merge the existing HPFF proposal for Interoperability (the "MAP_TO" proposal) with the existing WG5 draft TR on Interoperability (the "BIND" proposal). On the surface, this might be seen as providing a best-of- both-worlds solution. The user who doesn't want to have to worry about C data types in their Fortran program, can have the C data types specified in one place - the interface body. The user who wants to ensure that no copying of data occurs on procedure calls can use the ISO_C module to declare objects using kind-type parameters that correspond to those used in their C procedures. Unfortunately, there are cases that the MAP_TO approach fails to handle, and there are certain surprises that come with the MAP_TO approach: (1) WG5 has indicated that it would like the TR to handle C extern data. However, it is not possible for the MAP_TO approach to be used in that situation; on a reference to a procedure defined by C, there is no way of mapping from Fortran data types to the C data types for extern data. The kind type parameters of the ISO_C module will have to be used for variables of this sort. (2) WG5 has indicated that it disliked the idea of recursive MAP_TO specification of dummy arguments of derived type. The only other reasonable way of handling the problem is to permit MAP_TO to be specified with the derived type definition instead, or have the user use the kind type parameters defined in the ISO_C module. This contradicts the principle that the MAP_TO attribute only needs to be specified in interface bodies. (3) Several members of X3J3 have indicated that when users discover that a copy-in/copy-out mechanism is being used to pass arrays in some situations in most implementations, they rewrite their code to avoid those situations. The MAP_TO proposal actually requires copy-in/copy-out of dummy arguments in those situations in which the representation of the actual argument in the Fortran processor does not match the representation of the dummy argument used by the C processor. X3J3/96-145r1 Page 2 of 2 Users will be forced to either use the kind type parameters of the ISO_C module from the start, or resort to using them when they encounter an implementation for which the representations differ for Fortran and C. (4) The copy-in/copy-out approach also has other potentially surprising consequences. For example, INTERFACE BIND(C, 'SUB') SUBROUTINE SUB(A) REAL(KIND(0.0D0)), MAP_TO('double') :: A END SUBROUTINE SUB END INTERFACE X = 1.0D0 + 1.0D-16 PRINT *, X CALL SUB(X) PRINT *, X END may have the effect that two different values of X are displayed before and after the call to SUB, if the representation of double precision values is different from those of double values. It is not clear what would happen if A had been given INTENT(IN). (5) Finally, as has been pointed out before, copy-in/ copy-out causes special problems for Asynchronous I/O and other forms of parallelism. Requiring the semantics of copy-in/copy-out just introduces more headaches for implementations when these features are integrated. For these reasons, we would like to recommend that WG5 reconsider its decision to integrate the MAP_TO and BIND_TO approaches, and focus on the original BIND_TO approach.