[MPI3 Fortran] Notes from conf call on MPI function symbol naming convention for tools

[Bill Long]

On 7/7/11 11:48 AM, Rasmussen, Craig E wrote:
> Yesterday we had a conference call on the symbol naming convention for PMPI usage and tools.  There are two proposals on the table that we need to discuss and I'd ultimately like to take a straw vote on.  I'll try to present the two alternatives along with pros and cons for each choice.  For each choice I'll show portions of the interface declaration.
>
> Alternative 1:
>
>     interface MPI_Send
>        subroutine MPI_Send_f08(...) BIND(C,name="mpi_send_f08")
>           use mpi_f08
>           ...
>        end subroutine
>     end interface
>

This scheme seems to make sense, assuming rational things are 
substituted for the ... omissions. Since the mane="  " specifier 
specifies the name that would be used anyway if there were no name= 
specifier, the name= part is not really required. However, it is useful 
as documentation for readers who don't know Fortran very well.


> Synopsis: This method provides a well-known and fixed binding name.
>
> Pros:  This method provides a well-known and fixed binding name.  Thus C and Fortran PMPI and tools implementors will have a fixed C name (and thus symbol) to bind to.
>
> Cons: This method won't work for all compilers until they implement the interop TR.  The reason is that compilers will reject the TYPE(*), DIMENSION(..) syntax as well as character strings in a BIND(C) procedure.  However, it turns out most compilers support this interface using some kind of IGNORE TKR compiler directive, though wrapper functions for character strings would have to be used until the TR is implemented.
>
> This choice will force Fortran users of PMPI to use the BIND attribute and C name.
>
>
> Alternative 2:
>
>     interface
>        subroutine MPI_Send_f08(...)
>           use mpi_f08
>           ...
>        end subroutine
>     end interface
>

I don't understand this.  I expect that the user wants to call MPI_Send 
in his program.  This works fine with Alternative 1.  But here, it looks 
like the user has to explicitly call MPI_Send_f08, since there is no 
generic MPI_Send name available.    This seems like a big negative for 
Alternative 2.


> Synopsis:  This method has no C binding.
>
> Pros: It can be implemented now with existing compilers.  Fortran users of PMPI don't have to use the BIND attribute and get the C name correct.
>
> Cons: It forces MPI vendors to use non-standard binding names.  However, they (and tools people) have been doing this for years so this is a solved problem if not very elegant.  The biggest problem with this that when the TR is implemented, the BIND attribute will have to be used so that descriptors will be passed to the implementing routine.  The Fortran PMPI users will now have to start using the BIND attribute and the C binding label will be non-standard.  For example:
>
>      subroutine MPI_Send_f08(...) BIND(C, name="mpi_send_f08__)
>

This misses the whole point of bind(c).   If you are calling a C 
function from Fortran, the caller should have a bind(c) interface for 
the C function and the binding label should match name in the C 
function.  If you are calling another Fortran procedure, you do not need 
to specify bind(c) in the interface.

Cheers,
Bill


> Note the trailing underscores.  So not only will Fortran PMPI users have to add the BIND attribute at sometime in the future, they will have to do it is a non-portable way.  For some compilers they will use the BIND attribute, for others not and the binding label will almost always be different.
>
>
> I suppose there is a third alternative:
>
> The standard would specify alternative 1, but allow implementors the option of providing wrapper functions (as in alternative 2) that call a C function with an interface consistent with alternative 1 (in the interim until all compilers implement the Interop TR).
>
> -craig
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- 
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