(j3.2006) MPI usage problems in Fortran

[Bill Long]

Craig Rasmussen wrote:
>
> On Mar 21, 2008, at 11:13 AM, Bill Long wrote:
>
>> A couple of comments on the ideas below.
>>
>> 1) The ASYNCHRONOUS FUNCTION scheme is basically what some people call
>> 'futures'.  If we (WG5) want to go that direction, we should consider
>> how to do it in general.
>>
>> 2) Either the async functions, or the proposal to change the rules for
>> C_LOC() take the proposal out of conformance with f03.  If the idea is
>> to provide a facility that is usable with f03, then those options are
>> out.  If the idea is to make an interface for f08, for which we (barely)
>> have time for changes, or for a future f1x standard, then it would be
>> better, in my opinion, to directly address the root problem rather than
>> trying to twist existing syntax.  For example, we could add a type
>> C_VOID to the ISO_C_BINDING module, say that any data type can match
>> this in an interface, and that variables declared that way shall not
>> appear in a definition context, shall not be referenced, and shall not
>> be allocatable, pointer, or assumed-shape.  In other words, can't be
>> used outside an interface, and are pass by address, and not dope
>> vector.  Alternatives, like type(*), have been proposed in the past to
>> serve a similar function, though experience suggests that messing with
>> the basic typing syntax is unpopular.
>>
>> Another variation that has been discussed (and I would prefer) is to add
>> a LANG= spec to the BIND( ) syntax, which would enable you to specify
>> that an interface was for a function written in C and that type(C_VOID)
>> would be allowed only in such an interface, and disallow allocatable,
>> pointer, and assumed-shape for type(C_VOID) dummies.  You enforce the C
>> nature (or , at least non-Fortran nature) of the function by requiring
>> that the LANG= spec on the interface and the actual function definition
>> has to match , and that LANG="C"  is allowed only in an interface body.
>> Some of these ideas COULD be added into the C interop TR, which would be
>> better than messing with the base f08 document.  And it would allow the
>> MPI crowd to require f03 + TR rather than all of f08.
>
> I think the LANG=spec proposal would be widely welcomed by the MPI 
> community as they really want something to put in the MPI 3.0 spec and 
> so this would fit the f03 + TR time frame.
>
> Would this require something like C_LOC?

No. In the Call on the Fortran side you would just pass the BUF argument.

Something like:


interface
    subroutine MPI_xxx (buf, .....) bind(c,lang="C",name="MPI_xxx")
       import c_void
       type(c_void) :: buf(*)
       ...
     end subroutine MPI_xxx
end interface

call MPI_xxx (buf, ...)


No VALUE attribute for the buf dummy, or C_LOC() references on the 
actual. I've always cringed at the C_LOC(BUF) reference in the call for 
cases where you are actually defining BUF in the subroutine, which is 
about half the time for MPI codes.   This seems to make a lot more sense 
to me, and I suspect it would be more natural for the users of the MPI 
interface.

Cheers,
Bill


-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120