[Mpi-forum] ABI

[Jed Brown]

"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_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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20131205/e9ef19cd/attachment-0001.pgp>