nmm1 at cam.ac.uk
Thu Dec 5 10:39:09 CST 2013
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
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
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.
More information about the mpi-forum