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

[Rasmussen, Craig E]

On Jul 7, 2011, at 11:29 AM, Bill Long wrote:

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


Sorry, I messed up.  The interface for alternative 2 should have a name, as in

interface MPI_Send
   subroutine MPI_Send_f08(...)
   end subroutine
end interface

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

This problem is rather involved.  We are trying to provide hooks for tool writers so that they can intercept the MPI calls, perhaps start some timing routines, then call the PMPI_Send() which calls the "real" MPI implementation.  If this is still confusing, I'll call you and we can talk it out.

So it is really about providing hooks to the tool writers and so is more involved that simple interfaces to C routines.  I think we have worked out those details for the MPI-3 standard.  Now we are on to satisfying the tools folk which is mainly about what symbols they see.

-craig