[Mpi-forum] ABI

[Jed Brown]

Pavan Balaji <balaji at mcs.anl.gov> writes:

> Agreed.  I should also add one more item:
>
>  - Bug-fixes (or sorts): if we decide that our MAX_STRING_LENGTH is
>  too short and want to increase it, that’s going to be a pain in the
>  neck with ABI compatibility.  Everyone has to change it.  If
>  variables in the status object have interleaved 64-bit and 32-bit
>  objects, the compiler might pad them and waste space.  You can’t
>  reorder them without breaking ABI.

1. These are also issues within the "MPICH ABI team".

2. I'm not suggesting that the MPI_Forum should standardize an ABI.

3. Having MPICH typedef to intptr_t instead of int, and turning a bunch
   of integer constants implemented via macros into symbols defined in
   the library would go most of the way toward making it possible for
   OMPI to join the "team".

4. The private fields in the MPI_Status object do not need to have the
   same meaning, just the same size.  The MPICH struct currently has a
   "hole", but if you reordered the last two fields and ditched
   abi_slush_fund (or OMPI agreed to add one), it would be the same size
   as the OMPI struct.  Is this a real issue?

> Even if the eventual goal was for universal ABI compliance, I’d still
> recommend starting small with fairly similar MPI implementations, and
> then take the lessons learnt to other MPI implementations.

In this case, it's more like you're taking the same implementation,
forking it several ways, and then asking the forks to converge on their
modifications.

> And yeah, we are not going to switch to OMPI internal implementation
> conventions.  These are two different design choices, each of which
> has its own advantages.  

I proposed that you don't have to change those things to have a
compatible ABI on architectures that have the same calling convention
for pointers and integers of pointer size.  This is not universal, but
is the case for the common architectures.

> Isn’t that the point of having multiple implementations?  

I would not say that "the point" of multiple implementations is to have
different binary *interfaces*.  The point is to have different
*implementations*.  Now if there is a clear technical reason why the
binary interfaces cannot be compatible when the implementations are
different, there would be nothing to discuss.  (This is the case when
the source interface throws away all semblance of encapsulation, such as
with a C++ template library.)
-------------- 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/20131204/85ba4ff5/attachment-0001.pgp>