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

[Craig Rasmussen]

I actually like Bill's counter proposal.  My only suggestion is that an implementation must implement all of one or more of the options.  I think splitting the symbols up into various subsets needlessly complicates  things for everyone:  the standard, the implementations, the casual Fortran tool writer, and the C tool community.

Some MPI implementations could easily create a compile time option to build separate libraries with one providing C symbol interceptability and the other providing Fortran symbol interceptability.

By the way, Bill has a lot of experience on the Fortran standard's committee writing "standard legalese", something that is completely outside my skill set given my experience in writing text for scientific journals.  So perhaps he can help with some of the text.

Dictionary definition of legalese:  the formal and technical language of legal documents that is often hard to understand

Craig Rasmussen
CAS Scientific Programmer
rasmus at cas.uoregon.edu


On Apr 24, 2013, at 7:46 AM, Bill Long 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20130424/4f14c01e/attachment-0001.html>