[MPI3 Fortran] Fortran proposal w.r.t. BIND(C)/logical/linker symbols/etc. (take 2)
Bill Long
longb at cray.com
Fri Apr 26 14:41:16 CDT 2013
Interestingly, as I was writing the attached file, this email arrived.
I'll try to point out differences. Overall, the attached version
explicitly moves in the direction that Jeff suggested - that the spec
should not require a particular implementation.
On 4/26/13 1:26 PM, Jeff Squyres (jsquyres) wrote:
> With lots of feedback and discussions since Craig's+my proposal on April 22, we have updated our proposal to be the following (remember: if everyone likes these ideas, then we can go see what this means in terms of the text of chapter 17):
>
> 1. Remove BIND(C) from all prototypes in the spec.
>
Agreed.
> 2. As has been the case since MPI-1, all Fortran symbols must be interceptable at link time:
>
I guess I find this too vague. What is a "Fortran symbol" ? I prefer
to spell out explicitly the required names without trying to identify
whether the underlying code is written in Fortran, C, or Python. The
tools that care about this need to know only the external name and also
the calling convention used. That's enough as far as I can see.
[Note: In the attached file, I did take an extra step in exempting the
routines in A.2.12 through A.2.15 from having separate PMPI_* names.
These routines are so trivial that intercepting them would seem to make
no sense. Further, they are often only 1 line of code, so it would be
far better to have the compiler just inline them (resulting on no
external symbol to intercept). The tools library would, of course,
still have the MPI_* names available to call of needed. They would just
not intercept them.
> Class 1: For all MPI routines "MPI_<foo>" with a void * choice argument, or with no choice argument:
>
> A) If mpif.h/mpi module is provided, an external must be provided with the name "MPI_<foo>" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A.
>
An external name of MPI_<foo>, by definition in the spec, has the C
calling conventions, and already exists in the library this way. You
cannot have an MPI_<foo> with Fortran calling conventions, or INTEGER
arguments. I assume this is just a mistake. More likely, the name is
mpi_<foo>_.
Furthermore, this requirements conflates the external names with what
environment is being used. These should be independent issues.
> B) If the mpi_f08 module is provided, an external must be provided with the name "MPI_<foo>_<f08_buffer>" that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A.
>
Again, having the Fortran routine name start with upper case letters is
not a good idea. If this is not a mistake, it is doing what we are
trying to get away from - it puts an unnecessary constraint on the
implementation. To get a name of MPI_... you either have to specify
BIND(C) [with we are trying to get rid of], or it forces the
implementation to not write this routine in Fortran. That is the type
of restriction that we're trying to get rid of.
> Class 2: For all MPI routines "MPI_<foo>" with a descriptor choice argument:
>
> A) If mpif.h/mpi module is provided, an external must be provided with the name "MPI_<foo>_<old_descriptor>" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A.
>
> B) If the mpi_f08 module is provided, an external must be provided with the name "MPI_<foo>_<f08_descriptor>" that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A.
>
My impression from an earlier exchange with Rolf was that it is also an
option to have derived type handles and (void *) choice arguments.
This is only through the mpi_f08 module, for compilers that do not
support the TS yet. I included this option in my list (so I have 5
names, instead of the 4 listed here). If this combination is being
removed, then I'm happy to adjust my proposal accordingly.
> *** The exact suffixes <f08_buffer>, <old_descriptor>, and <f08_descriptor> are up for discussion.
>
Ditto for the MPI... as above.
> 3. Implementations that want to use CONTAIN blocks for inlined implementations -- probably for performance reasons -- can supply 2 Fortran libraries: one with CONTAIN/inlined implementations, and a second one with interceptable symbols (perhaps this should be an Advice to Implementors?).
>
This misses the main point. Sorry. There is no reason to have two
Fortran libraries. Or any Fortran libraries, for that matter, if the
implementation chooses some other method that satisfies the
requirements. The point, as you said before, is to not specify the
implementation.
Cheers,
Bill
--
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
-------------- next part --------------
17.1.5.1 Introduction
The Fortran interface provides two main facilities - conventions for
external linkage names and calling conventions so that tools can
intercept calls to the MPI library and execution environments for the
Fortran user based on the mpi module, the mpi_f08 module, or the
mpif.h include file. The requirements are specified, but not the
implementation details.
17.1.5.2 External linkage names and calling conventions
A Fortran call to an MPI routine shall result in a call to a procedure
with one of the following external linkage names and calling conventions.
MPI_Send is used as an example. Case is significant in the names.
External Linkage name Calling convention
--------------------- ------------------
1) MPI_Send C interface and arguments, as in A.2.
2) MPI_Send_cdesc Same as (1) except that choice arguments
are pointer to CFI_cdesc_t rather than
void *.
3) mpi_send_ Fortran interface and arguments, as in A.4.
4) mpi_send_f08_ Same as (3) except that handle arguments are
of the derived types specified in A.3 instead
of INTEGER.
5) mpi_send_f08ts_ Fortran interface and arguments, as in A.3.
For each external linkage name supported, a second entry point with
the same calling characteristics shall be supplied, expect that the
name is modified by prefixing with the letter "p" in the same case as
the leading "m". For example, PMPI_Send and pmpi_send_. The MPI
routines MPI_Wtime and MPI_Wtick, and the routines specified in A.2.12
through A.2.15 are not required to have a "P" prefix entry point.
17.1.5.3 Execution environments
An implementation shall provide two modules, mpi and mpi_f08, and one
include file, mpif.h, that Fortran program units can access in scopes
that have calls to MPI routines. A scoping unit shall not specify more
than one of these methods.
The module mpi provides for calls to MPI routines that either have no
handle arguments or have INTEGER handle arguments. It provides the
values of the handles specified in A.1 compatible with INTEGER arguments.
The module mpi_f08 provides for calls to MPI routines that either have
no handle arguments or have handle arguments of the derived types
specified in A.1 and A.3. It provides the values of the handles
specified in A.1 compatible with arguments of the derived types as
specified in A.3. The module mpi_f08 may specify choice arguments
declarations of TYPE(*),DIMENSION(..) if TS 29113 is supported by the
implementation, or traditional declarations for the choice arguments,
but not both.
The include file, mpif.h, provides the same user interface as the
module mpi. The use of mpif.h is discouraged. Use of one of the
modules is recommended instead.
More information about the mpiwg-fortran
mailing list