Subject: Suggested binding change for "get" functions

From: [email-masked] (James Cownie)
Date: Tue, 14 Dec 1993 11:04:05 +0000

People,

I propose that we change C and Fortran bindings of the
functions MPI_GET_SOURCE, MPI_GET_TAG and MPI_GET_COUNT, so that
they may be implemented more easily as macros in C or as statement
functions in Fortran. (We discussed this at one of the meetings, but
then it got lost in the rush to get areasonable text ou for SC93).

Rationale
=========
At least one of these three functions is likely to be called with each
receive which is preformed, thterefore minimising their cost is
extremely important, since it is effectively added to the message
passing latency. 

The loss of an error indication from these functions is a small price
to pay, since there are unlikely to be any error conditions detectable
at this point anyway.

Suggested changes
=================

First various misstatements which require correction anyway, the text
states that the status object must have been set by a receive. What we
want is a receive or a probe. Therefore :-
Page 18: line 26 : "by a receive" should read "by a receive or probe "
         line 27 : "by a receive" should read "by a receive or probe "

Similar changes required to definitions of the functions (line 39,
page 19 line 1).

Need some discussion in GET_COUNT of legal datatypes when used after
probe, (since probe doesn't pass in a datatype the statement here
needs to be expanded to handle probe).

Add new paragraph at page 18 line 28:

Since these functions are expected to be very cheap (as they are
simply unpicking a structure in user space), called very
often, and are incapable of detecting errors, we choose to adopt a
different binding for these functions, in which the result of the
function is the "natural" result of the query, rather than an error
condition. In the C binding we expect that these "functions" will be
implemented as macros, therefore users should NOT rely on single
evaluation of the arguments to these functions. (i.e. code like
	tag = MPI_Get_tag(statuses[i++]);
is erroneous because of the side effect in the argument).

New bindings in the obvious way

int MPI_Get_source(int *status)

INTEGER FUNCTION MPI_GET_SOURCE(STATUS)
INTEGER STATUS(MPI_STATUS_SIZE)

and similarly for the other two.

Also need a statement in the profiling chapter that you can't expect
to profile these macros !

--Jim
James Cownie 
Meiko Limited			Meiko Inc.
650 Aztec West			Reservoir Place
Bristol BS12 4SD		1601 Trapelo Road
England				Waltham
				MA 02154

Phone : +44 454 616171		+1 617 890 7676
FAX   : +44 454 618188		+1 617 890 5042
E-Mail: [email-masked]   or    [email-masked]

---

From: Rusty Lusk <[email-masked]>
Date: Tue, 14 Dec 1993 06:46:27 -0600

Although I agree with what you say, it is not strictly necessary to change the
bindings to be able to define them as macros.  The model implementation
currently defines them this way:

#define MPI_Get_source(status,src)      ((src) = (status).source,MPI_OK)
#define MPI_Get_tag(status,tg)          ((tg)  = (status).tag,MPI_OK)
#define MPI_Get_count(status,cnt)       ((cnt) = (status).count,MPI_OK)

Admittedly, this does not address the issue that they are more naturally
implemented as functions in Fortran, and hides the fact that no bad return
codes are possible.

Rusty

---

From: [email-masked] (James Cownie)
Date: Tue, 14 Dec 1993 13:15:55 +0000

> bindings to be able to define them as macros.  
You are correct, though I'd like to make it explicit that they may be
macros, so that 
1) we can outlaw side effects in the arguments (though actually it's
   probably safe anyway provided the macros are similar to yours, where
   each argument is expanded once only)
2) we can make clear that trying to intercept these using the
   profiling tricks won't work !

> The model implementation

Surely these are wrong, the result argumnts are supposed to be (int *),
so shouldn't the macros look like

#define MPI_Get_source(status,src)      ((*(src) = (status).source),MPI_OK)

(or am I wrong somewhere ? The code presumably works !)

The other point is that even with macros as above, the current binding
looks unpleasant, and may impede code optimisation, since some
compilers are not very clever at handling things whose address is
taken (even in an expression like *(&s)). The current binding also forces
the user to create a temporary which is often unnecessary, e.g.

{
    int tag;

    MPI_Get_tag(status, &tag);

    switch(tag)
    {
    }
}	

compared with simply

    switch( MPI_Get_tag(status) )
    {
    }

Maybe consistency of interface is more important though. In any case
lets say that they're probably macros...
	
-- Jim
James Cownie 
Meiko Limited			Meiko Inc.