[MPI3 Fortran] MPI-2.1: Fortran 90 bindings

Lionel, Steve steve.lionel at intel.com
Thu Mar 6 07:25:08 CST 2008


I would recommend that for buffers of variable type and rank that the
Fortran interface make use of the Fortran 2003 C interoperability
features, supported by many compilers already, and make these arguments
of type C_PTR passed by value.  The programmer would then pass
C_LOC(buffer), where buffer can be of any type and rank.  This is all
specifiable with standard-conforming syntax.

If this is done, you don't need to have multiple interfaces just to
change type, and you're not giving up any type checking that you would
have had before, as any combination of type and rank would have matched
some interface. Now you can have as many of these "variant" arguments as
you like without a mind-numbing series of specific interfaces.

A compiler using this choice must support the following Fortran 2003
features:
- Intrinsic module ISO_C_BINDING
- The VALUE attribute
- The BIND(C) attribute

And if the user chooses a compiler that does not support this, then they
can use the F77 interfaces.

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH



-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org
[mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Jeff
Squyres
Sent: Wednesday, March 05, 2008 9:16 PM
To: Mailing list for discussion of MPI 2.1
Cc: MPI-3 Fortran working group
Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
Importance: Low

The current MPI-2 F90 bindings are un-implementable because they  
require almost 7 *million* interface functions: with 15 intrinsic  
Fortran types, each with 7 possible dimensions, the current F90  
interface *requires*:

- 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions
- 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M  
functions
- ...and a few hundred more MPI functions with no choice buffers

This is clearly broken.

An MPI-2.1-worthy solution could be to add a global statement saying  
that MPI functions with two choice buffers are explicitly not included  
in the F90 bindings.  F90 MPI applications can transparently fall back  
to the F77 bindings (although they won't get the strong type checking,  
etc.).  This idea therefore fits the requirement of not breaking any  
existing MPI codes.

Specifically: if we remove the requirement to provide all MPI  
functions with two choice buffers, 5,000+ F90 interface functions is  
[a pain but] implementable.  I doubt that any current MPI  
implementation provides more than the no-choice-buffers plus one- 
choice-buffer functions anyway...

If this seems like a good idea, I can write a proper proposal for it.   
Comments?

-- 
Jeff Squyres
Cisco Systems

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran




More information about the mpiwg-fortran mailing list