[MPI3 Fortran] Fortran proposal w.r.t. BIND(C)/logical/linker symbols/etc. (take 2)

[Bill Long]

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.