[MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.

[Jeff Squyres (jsquyres)]

Craig walked me through Bill's proposal on the phone today.  Here's my take:

1. With one exception, I agree with Bill's proposal... but for reasons different than his (see below).
2. The one exception is class 2 point 1: Craig and I would like to defer some mechanism like this to MPI-4.

The reason that I agree with this proposal is because it is largely already covered by MPI-3 *because MPI-3 already says that the Fortran interfaces are optional* (i.e., the “AT LEAST ONE OF...” language can refer to the optionality of the Fortran interfaces, not linker symbols).  Because of that fact, this proposal redundant/unnecessary (although I like the categorization of class1/2, etc.).

Additionally, Rolf and Hubert have convinced me (off list) that the ABI issue is important and we need to retain the behavior that was published in MPI-3 (i.e., that MPI subroutines that accept buffers have one standardized linker name, and MPI subroutines that accept descriptors have a second standardized linker name).

I'll start a new thread (just because this one is already long) with all the feedback that we’ve gotten so far, to include the 2-library proposal, etc.




On Apr 24, 2013, at 10:46 AM, Bill Long <longb at cray.com> wrote:

> 
> 
> On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote:
>> On Apr 24, 2013, at 9:36 AM, Bill Long <longb at cray.com> wrote:
>> 
>>>> You're imposing a specific implementation scheme.  We can't allow that in the MPI spec.
>>> 
>>> I disagree with the first sentence.  I'm wanting to merely ALLOW a new scheme (which is  better one that the current lot, in my opinion).
>> 
>> Rolf's proposal mandates 3 specific implementation schemes.  So I should have said "Rolf", not "you".  :-)
>> 
>>> So you are saying that disallowing better implementations is part of the mandate of the MPI spec?
>> 
>> Don't be like that.
>> 
> 
> I didn't mean to be mean. The Fortran standard has a lot of instances of disallowing things, and I was not sure if the same was true of MPI.
> [I'm in the middle of a symposium all day today, so sorry about not being prompt with replies.]
> 
>>>> One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices.  Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented.
>>> 
>>> Then I see that as a problem.  We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different.
>> 
>> 
>> The MPI spec takes great pains to not mandate any particular implementation at all.
>> 
> 
> My view (inexperienced as it is) is that this section is mainly about specifying what symbol names need to be available so that the tools know what to look for/intercept.  I'd be in favor of just listing the names and characteristics without commentary about how they get produced (i.e. remove the discussion about the implementation detail).  Something like to following:
> 
> Class 1:  For an MPI routine MPI_xxx with a void * choice argument, or with no choice argument, the implementation shall provide at AT LEAST ONE of the following:
> 
> 1) An external with the C name MPI_xxx and C calling conventions as specified in the C prototype in Annex A.
> 
> 2) An external with the name "......" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A.
> 
> 3) An external with the name "....." that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A.
> 
> 
> Class 2: For an MPI routine MPI_xxx with a descriptor choice argument, the implementation shall provide AT LEAST ONE of the following:
> 
> 1) An external with the C name MPI_xxx_cdesc and C calling conventions...
> 
> 2), 3) Similar to above.
> 
> With rules like these, a tool would have a small list of names to look for, and the correct calling information about each.
> 
> 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
> 
> 


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/