<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I actually like Bill's counter proposal. My only suggestion is that an implementation must implement all of one or more of the options. I think splitting the symbols up into various subsets needlessly complicates things for everyone: the standard, the implementations, the casual Fortran tool writer, and the C tool community.</div><div><br></div><div>Some MPI implementations could easily create a compile time option to build separate libraries with one providing C symbol interceptability and the other providing Fortran symbol interceptability.</div><div><br></div><div>By the way, Bill has a lot of experience on the Fortran standard's committee writing "standard legalese", something that is completely outside my skill set given my experience in writing text for scientific journals. So perhaps he can help with some of the text.</div><div><br></div><div>Dictionary definition of legalese: <span class="Apple-style-span" style="font-size: 13px; "> </span><span class="Apple-style-span" style="font-family: Baskerville; font-size: 13px; ">the formal and technical language of legal documents that is often hard to </span><span class="Apple-style-span" style="font-family: Baskerville; font-size: 13px; "><span apple_mouseover_highlight="1">understand</span></span></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Craig Rasmussen</div><div>CAS Scientific Programmer</div><div><a href="mailto:rasmus@cas.uoregon.edu">rasmus@cas.uoregon.edu</a></div><div><br></div></div></span></span>
</div>
<br><div><div>On Apr 24, 2013, at 7:46 AM, Bill Long wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br>On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote:<br><blockquote type="cite">On Apr 24, 2013, at 9:36 AM, Bill Long <<a href="mailto:longb@cray.com">longb@cray.com</a>> wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">You're imposing a specific implementation scheme. We can't allow that in the MPI spec.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I disagree with the first sentence. I'm wanting to merely ALLOW a new scheme (which is better one that the current lot, in my opinion).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Rolf's proposal mandates 3 specific implementation schemes. So I should have said "Rolf", not "you". :-)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">So you are saying that disallowing better implementations is part of the mandate of the MPI spec?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Don't be like that.<br></blockquote><blockquote type="cite"><br></blockquote><br>I didn't mean to be mean. The Fortran standard has a lot of instances of disallowing things, and I was not sure if the same was true of MPI.<br> [I'm in the middle of a symposium all day today, so sorry about not being prompt with replies.]<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Then I see that as a problem. We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The MPI spec takes great pains to not mandate any particular implementation at all.<br></blockquote><blockquote type="cite"><br></blockquote><br>My view (inexperienced as it is) is that this section is mainly about specifying what symbol names need to be available so that the tools know what to look for/intercept. I'd be in favor of just listing the names and characteristics without commentary about how they get produced (i.e. remove the discussion about the implementation detail). Something like to following:<br><br>Class 1: For an MPI routine MPI_xxx with a void * choice argument, or with no choice argument, the implementation shall provide at AT LEAST ONE of the following:<br><br>1) An external with the C name MPI_xxx and C calling conventions as specified in the C prototype in Annex A.<br><br>2) An external with the name "......" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A.<br><br>3) An external with the name "....." that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A.<br><br><br>Class 2: For an MPI routine MPI_xxx with a descriptor choice argument, the implementation shall provide AT LEAST ONE of the following:<br><br>1) An external with the C name MPI_xxx_cdesc and C calling conventions...<br><br>2), 3) Similar to above.<br><br>With rules like these, a tool would have a small list of names to look for, and the correct calling information about each.<br><br>Cheers,<br>Bill<br><br><br><br>-- <br>Bill Long <a href="mailto:longb@cray.com">longb@cray.com</a><br>Fortran Technical Support & voice: 651-605-9024<br>Bioinformatics Software Development fax: 651-605-9142<br>Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101<br><br><br></div></blockquote></div><br></body></html>