Hi Greg, 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.
Patrick -- Patrick Geoffray Myricom, Inc. http://www.myri.com
