[MPI3 Fortran] Deprecate mpif.h?
longb at cray.com
Mon Mar 8 08:20:49 CST 2010
N.M. Maclaren wrote:
> On Mar 7 2010, Bill Long wrote:
>> Removing the requirement that types of actual and dummy arguments match
>> is the sole purpose of type(*). I'm not sure what Nick means by 'the
>> actual type will still have to be passed'. There is no requirement or
>> intention that some extra information indicating the type of the actual
>> argument be passed to the subprogram. If an actual argument of type X
>> is passed to a subprogram that has an interface where the corresponding
>> dummy argument is specified type(*), and the subprogram is a function
>> written in C, then the interpretation of the argument in the function
>> should be as if it were declared type X.
> This is in the context of MPI choice arguments, where the information is
> provided by the MPI datatype argument.
> However, in general (i.e. not just MPI), TYPE(*) isn't useful unless you
> pass the type some other way - because, except in a few cases, C needs to
> know the actual type X to make use of the argument. And, if an interface
> is used only for a single type, why use TYPE(*)?
The classic example is a 'memory copy' routine where you care about the
starting addresses of the source and destination and the number of bytes
to move, but are not interested in the type of the data represented by
the bits in memory. (MPI seems to have numerous variants on this idea.)
>> Fortran provides various argument passing semantics, which are most
>> often implemented in these three ways [noting that Fortran character
>> arguments are often an exception, and that none of these implementations
>> is specified in the standard]:
> Those ARE specified for BIND(C), which is what C people need to know
> about. Fortran's internal mechanisms are quite likely to be different,
> in at least some cases, but it would be unnecessarily confusing to
> discuss the possibilities.
Good point. The bind(c) specs in Fortran 2003 cover the value and
address (1 and 2) cases. The point of the TR is to extend bind(c)
interfaces to handle the descriptor (3) case.
>> 1) Call by value. The actual value of the argument is passed - a
>> concept very much like the same in C, and designed for interoperability
>> with C.
> Unlike in C, it's a true read-only value, and not the initial value of
> an updatable variable. C people need to note that.
Huh? In Fortran a VALUE dummy argument gets its initial value from the
corresponding actual argument. Within the subprogram, its value can
change, but at the return to the caller any change in the value is not
propagated back to the actual argument. It is as if a copy-in temp for
the actual were made, but with no copy-out. Often the 'copy-in' is into
a register. I thought this was much like how C treats such arguments,
and the design of the VALUE attribute is to be compatible with C. The
feature is sufficiently useful that VALUE is available in any interface,
not just those that specify bind(c).
There is a completely separate concept in Fortran, INTENT(IN). If that
is specified for a dummy argument, then the dummy cannot be redefined in
>> Specifying an allocatable dummy argument is only interesting if there is
>> some reason to allocate or deallocate memory for it. For the usual
>> send/receive routines this is not an issue. An actual argument with the
>> allocatable attribute can be associated with an assumed-size dummy (i.e.
>> what is currently done in f77-style interfaces).
> Yes, but MPI_Recv could specify that it would allocate or reallocate the
> buffer to the appropriate size. As I said, I don't like this, but some
> people do. MPI needs to consider it, though I would recommend NOT doing
> it, on the grounds of least confusion.
In my experience with MPI (admittedly limited compared to most on this
list), it seems that normally the receiving memory block is already
allocated - such as a set of halo cells that are part of a larger data
structure. If you really wanted this sort of automatic receiver
allocation facility, you could write a wrapper routine that did the
allocation and then called the normal MPI_Revc routine. That would seem
overall better than monkeying up the base routine to accommodate a
rarely used capability.
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
More information about the mpiwg-fortran