[Mpi3-tools] [Mpi-forum] Did we screw up the const bindings in MPI-3?

[Schulz, Martin]

Hi Marc-Andre,

On May 25, 2013, at 2:52 PM, Kathryn Mohror <kathryn at llnl.gov>
 wrote:

> Hi Marc-Andre,
> 
> Yes, we probably should move this discussion to tools from now on since it's getting into more technical details. Please send the information about your wrapper generator to both me and Martin.

Yes, please do.

> 
> Thanks!
> Kathryn
> 
>> 
>>> I haven't tried it with PnMPI (I'll try to do that before the meeting
>>> in San Jose), but we scan the mpi.h file. We have found this
>>> generally to be a good idea, since not always all routines are
>>> implemented and the tool works for MPI-1 and MPI-2 alike.
>> 
>> In Scalasca and Score-P, we inspect the MPI library for the presence each PMPI symbol and then we only create wrappers for those calls where we found valid PMPI symbols. (When the prototypes are mangle, this would definitely need to be adapted.)

I remember this now - this obviously serves the same purpose as our parsing for what we wanted to achieve.

>> The prototypes are predefined in an XML file. There, we also define additional attributes, such as whether a parameter in "input, output, or both".

We were thinking about something like as well - add semantics somewhere so more tools code can be generated.

>> 
>>> From a tools community point of view it would be good to come with
>>> such a wrapper generator once and then have everyone use it, which
>>> would not only eliminate this issue, but also make the Fortran issue
>>> much simpler.
>> 
>> As different tools groups might have different interests, it would be quite an undertaking. Still, it would definitely be good not to reinvent the wheel several times.

The latter is why I would like to see if we can do this - the C issues are minor, but the Fortran part is getting too complicated to re-invent the wheel. Also, based on all the discussions that we had I am starting to wonder if anyone of us got right for all cases.

>> 
>>> The tools WG is planing to have a discussion in San Jose on whether
>>> we can create such a wrapper infrastructure that actually produces
>>> Fortran implementations along with the C implementations, which may
>>> make the whole symbol naming issue unnecessary. Adding a C version to
>>> such a wrapper system would be trivial.
>> 
>> Unfortunately, I won't be in San Jose. Maybe I'll prime someone (Martin? Kathryn?) with what our wrapper generator can and cannot do, as input into the discussion?

Sounds good.

>> 
>> Cheers,
>> Marc-Andre
>> 
>> PS: Should we move this discussion to the tools mailing list?

Good idea - done.

Martin


>> -- 
>> Marc-Andre Hermanns
>> German Research School for
>> Simulation Sciences GmbH
>> c/o Laboratory for Parallel Programming
>> 52062 Aachen | Germany
>> 
>> Tel +49 241 80 99753
>> Fax +49 241 80 6 99753
>> Web www.grs-sim.de
>> 
>> Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
>> Registered in the commercial register of the local court of
>> Düren (Amtsgericht Düren) under registration number HRB 5268
>> Registered office: Jülich
>> Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> 
> ______________________________________________________________
> Kathryn Mohror, kathryn at llnl.gov, http://people.llnl.gov/mohror1
> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
> 
> 
> 
> 

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA