"N.M. Maclaren" <[email protected]> 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_MAX_PROCESSOR_NAME MPI_MAX_LIBRARY_VERSION_STRING MPI_MAX_ERROR_STRING MPI_MAX_DATAREP_STRING MPI_MAX_INFO_KEY MPI_MAX_INFO_VAL MPI_MAX_OBJECT_NAME MPI_MAX_PORT_NAME MPI_VERSION MPI_SUBVERSION 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 compile-time constants?

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?