[Mpi-forum] ABI

[N.M. Maclaren]

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.