[Mpi-forum] ABI

[Jeff Hammond]

Any chance that Intel will issue a patent license for anyone to create
a non-commercial, open-source implementation of
http://www.google.com/patents/US7966624?

Jeff

On Thu, Dec 5, 2013 at 4:04 AM, Supalov, Alexander
<alexander.supalov at intel.com> wrote:
> Hi everybody,
>
> We looked into this matter in substantial detail back in the times of ABI WG (pre-MPI-2.1, I think). Details can be found in https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage#no1 .
>
> Best regards.
>
> Alexander
>
> -----Original Message-----
> From: mpi-forum [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of N.M. Maclaren
> Sent: Thursday, December 05, 2013 10:44 AM
> To: Main MPI Forum mailing list
> Subject: Re: [Mpi-forum] ABI
>
> On Dec 4 2013, Jed Brown wrote:
>>
>>However, the question of integer (MPICH) versus pointer (OMPI) handles
>>is a long-standing impasse.
>
> Yes, but I don't think that it's the worst issue.
>
>>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.
>
>> This
>>leaves a question of the predefined constants, which are currently
>>compile-time constants of some sort (either integers or addresses of
>>privately-defined structs), but I'm not aware of text in the standard
>>that requires them to be defined in a header.  That is, can we have
>>
>>  extern MPI_Datatype MPI_INT;
>>
>>in the header and leave it to the library to provide the value?
>
> The killer there is whether they can be used in initialisations.  That would break:
>
>     static MPI_Datatype weeble = MPI_INT;
>
> 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.
>
>     Implementation assumptions.  Not just signals and threading, but the handling of stdin/stdout/stderr, passive one-sided and more.
>
> This doesn't mean that it can't be done, merely that it isn't as easy as just agreeing the types and values.
>
>
> Regards,
> Nick Maclaren.
>
>
>
>
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
> Registergericht: Muenchen HRB 47456
> Ust.-IdNr./VAT Registration No.: DE129385895
> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum



-- 
Jeff Hammond
jeff.science at gmail.com