[MPI3 Fortran] Deprecate mpif.h?

[Bill Long]

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 
the subprogram.

>  
>> 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.

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