Greg Lindahl wrote:
> I think this overall idea falls short of the benefit of an ABI for a
> couple of reasons. The first is that it's unlikely to get wide
> distribution if it doesn't come with MPI implementations. The second
> is that it's harder to maintain "out of tree"; the minute that an MPI
> implementation changes something, MorphMPI is going to be broken.
I don't see it that way. First, the implementations of the translation
layers will be done by each MPI implementations. MorphMPI (no offense
Jeff but we got to choose a somewhat cooler name) just define the common
interface, nothing more. If the common layer does not change, the
translation does not have to change unless something in the side of the
MPI implementation changes, and its maintainer should then keep its
local translation layer up to date.
> Was there a big fight over the Fortran interface? It nails down the
> types because it has to. All the ABI does is make C look like Fortran;
> no internals need change in any implementation.
You don't change internals, you translate them. Let say you use pointers
in your MPI implementation and the common layer specifies integers. In
your translation layer, you translate pointers into integers by putting
them in a table. You have as much work as your internals are far from
the common interface and, hopefully, it will be a midpoint for everybody.