On Dec 5 2013, Jed Brown wrote:

...

...

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?

Eh? I was saying that you shouldn't bet on pointers being treated the same as integers in all common calling conventions. I am not familiar with ALL current calling conventions - and remember that many ports work from the distributed base of OpenMP and MPICH, so are not within the platforms in the distributed source. As I said, this most definitely used NOT to be the case until quite recently, and I have no evidence that it has changed! Furthermore, this is NOT purely a hardware matter, and several of the differences I remember were entirely due to the compiler's choices.

...

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;

...

So these are link-time constants and the user can write

static MPI_Datatype weeble = MPI_INT;

There is no such concept in the C standard. They are not initialization constants (the relevant concept), as can be seen by failing to compile: typedef int MPI_Datatype; extern const MPI_Datatype MPI_INT; static MPI_Datatype weeble = MPI_INT; with gcc -std=c99 -pedantic -Wall -Wextra -O3 -c.

...

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?

Eh? I said that there were differences between MPI implementations, and by that I meant their semantics.

...

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?

Because the purpose of binary interfaces is to allow the exchangeability of compiled code. Merely getting programs to link and ensure compatible data formats is not enough - people rather like their programs to actually work! I have been involved in a couple of ABI standardisation, and the semantic issues were much nastier than the simple external name, data type and calling convention ones. Regards, Nick Maclaren.