Pavan Balaji <[email protected]> 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.)