[MPI3 Fortran] Summary of items on the table

[Craig Rasmussen]

Requirements:
1. Poorly defined interfaces now
2. type safety
3. no wrappers

On Apr 28, 2008, at 1:12 PM, Craig Rasmussen wrote:

> There has been quite a lot of traffic in the past couple of months
> regarding possible directions for a new MPI binding for Fortran.  I
> thought now would be a good time to summarize and try to get a
> consensus on what direction we should pursue.  Some choices will
> require changes to the Fortran standard and this input we need to get
> to the Fortran standards committee within the next two weeks.
>
> The major choice we need to make is how to declare an MPI "choice
> buffer" (void *) in a Fortran interface.  I'll list the options below
> with advantages and disadvantages as I see them.  Please rank these
> options (they all will use F2003 BIND(C)).
>
> 1. Map void* to C_PTR.  Upside: this will work now in most compilers
> and likely all soon.  Downside: users must change the call site to
> use C_LOC to obtain the C address; C_LOC requires the POINTER or
> TARGET attribute and may reduce performance and require additional
> code changes.

worried about performance and C_LOC for actual argument, users might  
revolt because of changes in code and performance

>
> 2. Map void* to a new Fortran type C_VOID.  Upside: no changes to
> current code (I think). Downside: would require a change in the
> Fortran standard and couldn't be done until Fortran 20xx (a long time
> before we see it in compilers).
>

OK.

> 3. Map void* to type(C_VOID) defined in the ISO_C_BINDING intrinsic
> module and add LANG=C to the Fortran standard.  Upside: no changes to
> current code other than to USE the MPI3 module.  Downside: it will
> require changes to the Fortran standard but can get to users
> relatively soon (before F2008 appears in compilers).
>

OK

> 4. Add an IGNORE attribute with parameters T (type) K (kind) R (rank)
> for BIND(C) interfaces.  This pretty much (as I understand it) does
> the same thing as #3, just with different syntax and with slightly
> more flexibility (partial type checking).  Upside: see #3.  Downside:
> see #3.
>

OK, although to declare a type and then ignore it seems ackward.

> Aleks has submitted a proposal to the Fortran J3 committee to improve
> on the ASYNCHRONOUS attribute.  Hopefully this can make it into the
> F2008 standard and fix problems associated with copyin/copyout
> semantics and with code motion associated with asynchronous MPI
> calls.  A question I have is there a problem with copyin/copyout for
> synchronous MPI?
>
> I'm currently at the April MPI Forum where I'll collect votes.
> Others please add your feedback (rank the options) in email (actually
> it would be helpful for the record to get email from everyone within
> shouting distance).
>
> A question just came up about passing CHARACTER parameters.  Comments?
>
> Regards,
> Craig
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran