jedbrown at mcs.anl.gov
Thu Dec 5 09:25:01 CST 2013
"N.M. Maclaren" <nmm1 at cam.ac.uk> writes:
>> Suppose MPICH used intptr_t for handles. I believe pointers are treated
>> the same as integers for all the common calling conventions.
> I wouldn't bet on it, especially not in the medium term. It's true on
> systems like the x86 (and its predecessor in dominance System/370), but
> I don't know all of the systems that either of those has been ported to.
> It certaainly used not to be the case.
1. I never suggested having the Forum standardize an ABI.
2. Why prevent something good just because some vendor some day might
build a CPU that handles pointers in a way that has not been seen on any
popular architecture in decades?
> The killer there is whether they can be used in initialisations. That
> would break:
> static MPI_Datatype weeble = MPI_INT;
Sorry, both MPICH and OpenMPI's mpi.h would contain:
extern const MPI_Datatype MPI_INT;
MPICH's mpi.h would have
typedef intptr_t MPI_Datatype;
while OMPI's mpi.h would have
typedef struct ompi_datatype_t *MPI_Datatype;
In some source file going into libmpi.so, MPICH would have
const MPI_Datatype MPI_INT = ((MPI_Datatype)0x4c000405);
while OMPI would have
const MPI_Datatype MPI_INT = ((MPI_Datatype)&ompi_mpi_int);
So these are link-time constants and the user can write
static MPI_Datatype weeble = MPI_INT;
They cannot use MPI_INT as a label in a case statement, but the standard
is explicit about that not being necessary (2.5.4 "Named Constants").
All named constants, with the exceptions noted below for Fortran, can
be used in initialization expressions or assignments, but not
necessarily in array declarations or as labels in C switch or Fortran
select/case statements. This implies named constants to be link-time
but not necessarily compile-time constants. [...]
The constants that are required to be compile-time constants (and can
thus be used for array length declarations and labels in C switch and
Fortran case/select statements) are:
MPI_STATUS_SIZE (Fortran only)
MPI_ADDRESS_KIND (Fortran only)
MPI_COUNT_KIND (Fortran only)
MPI_INTEGER_KIND (Fortran only)
MPI_OFFSET_KIND (Fortran only)
MPI_SUBARRAYS_SUPPORTED (Fortran only)
MPI_ASYNC_PROTECTS_NONBLOCKING (Fortran only)
> Lastly, there are some very nasty differences that would have to be
> tackled, such as:
> Attributes (especially the I/O ones). I meant to propose some fixes
> for MPI 3 (the current specification is weird), but didn't do it. Sorry.
> But there are probably quite a lot of such corner-cases.
Can you explain? Where does the standard require these to be
> Implementation assumptions. Not just signals and threading, but
> the handling of stdin/stdout/stderr, passive one-sided and more.
What does this have to do with the *binary* interface?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the mpi-forum