<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Here's Nick's reply. Thanks Nick!<br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"N.M. Maclaren" <<a href="mailto:nmm1@cam.ac.uk">nmm1@cam.ac.uk</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">January 26, 2010 8:15:24 AM EST<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"Jeff Squyres (jsquyres)" <<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Cc: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"Darius Buntinas" <<a href="mailto:buntinas@mcs.anl.gov">buntinas@mcs.anl.gov</a>>, "Main MPI Forum mailing list" <<a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: [Mpi-forum] MPI_Count</b><br></span></div><br>
<div>
<!-- Converted from text/plain format --><p><font size="2">On Jan 26 2010, Jeff Squyres wrote:<br>
>On Jan 25, 2010, at 4:33 PM, Darius Buntinas wrote:<br>
><br>
>> >> There are many different ways where<stdint.h> integers cause<br>
>> >> portability, efficiency and other problems. Inter alia, the current<br>
>> >> revision of C is thinking of changing them in ways that could be<br>
>> >> incompatible with old code, and they are semantically incompatible<br>
>> >> with Fortran and many other languages in several respects.<br>
><br>
>> Did the person state what the portability issues with int64_t could be?<br>
>> Is there a C "basic type" that would be compatible with a fortran<br>
>> INTEGER*8? BTW, we already added stdint datatypes to MPI 2.2.<br>
><br>
> Nick -- most people thought using "MPI_Count" as a type is fine, but I,<br>
> too, am curious about Darius' question (above). Could you comment? (if<br>
> you're not a member of the mpi-forum list, I can forward your reply)<br>
<br>
Certainly. Please forward this, if relevant. But let me start with<br>
a subsidiary point.<br>
<br>
On political grounds, I accept that there is no alternative but to add<br>
the major <stdint.h> names, but there is no realistic way that MPI can<br>
support all of <stdint.h>. Inter alia, it is an open-ended<br>
specification, and the complete set of types and their semantics is not<br>
even implementation-defined.<br>
<br>
Here is a subset of the reasons that <stdint.h> is ill-defined (which is<br>
a major obstacle to portability) or explicitly non-portable - references<br>
are to C99:<br>
<br>
Most people believe that int8_t, uint8_t, int16_t, uint16_t int32_t,<br>
uint32_t, int64_t, uint64_t, intptr_t and uintptr_t are required, and<br>
they are certainly the most commonly used names. They are wrong, and<br>
those names are optional, for very good reasons (see 7.18.1.1#3 and<br>
7.18.1.4#1). Does MPI specify them as required or optional? It should<br>
do the latter.<br>
<br>
The existence of intptr_t, uintptr_t, intmax_t and uintmax_t all block<br>
implementations from extending their pointer and integer semantics<br>
upwards compatibly (see 7.18.1.4 and 7.18.1.5). The former is a very<br>
serious issue, as experience has shown. But pointers are now and<br>
henceforth all 64 bits, right? That's doubtful. That blocks<br>
implementations from extending them to allow 'capability' pointers<br>
(e.g. IBM i series, a.k.a. i5/OS or OS/400), and might block<br>
thread-specific pointers (i.e. with a thread id as part of the pointer<br>
value). Some experts think that the latter are essential for the<br>
computers of 2020 and onwards. I should HOPE that MPI is planning<br>
on that timescale.<br>
<br>
It is undefined whether the type names are typedefs of any of the basic<br>
integer types, other standard integer types (e.g. size_t), other<br>
extended integer types or are new integer types, even if they have<br>
identical characteristics (see 6.2.5#4, 6.3.1.1#1 and 7.18,<br>
especially #1, #4 and footnote 215). Because typedefs are synonyms and<br>
new types are not, this affects the promotion and type compatibility<br>
rules and hence whether (at least some) programs AND SPECIFICATIONS are<br>
portable. MPI needs to be VERY careful that it doesn't trip across this<br>
one by accident, because it involves parts of the C standard that few<br>
people ever reach.<br>
<br>
Exact-width integer types (7.18.1.1) are a mess. #1 says that they<br>
must have a two's complement representation and no padding bits, but<br>
#3 requires them to be specified if an implementation has any integers<br>
of the specified width (see 6.2.6.2#6). They were claimed to be needed<br>
for external data formats, but that's largely pointless without<br>
specifying endianness and (more seriously) overflow semantics (see<br>
6.2.6.1#5 and 6.2.6.2#2). There are already several incompatible views<br>
on what their specification means. If that ever reaches the point that<br>
the problem can't get swept under the carpet, expect a religious war.<br>
<br>
Following on from that, even C's basic model is a subset of 'pure<br>
binary' with two's complement and wrapping on overflow preferred. Will<br>
other architectures (e.g. decimal) return? It's unclear - Intel and IBM<br>
are going to deliver decimal floating-point (see IEEE 754 2006), and<br>
some of the same people favour restoring decimal integers next. And,<br>
yes, their long-term intent is for SOLELY decimal arithmetic! Will<br>
they make any headway? Dunno. MPI should follow Fortran in not<br>
assuming whether they will succeed or fail.<br>
<br>
But, even today, C's semantic model is incompatible with many other<br>
important languages (e.g. Fortran, Cobol, Python and others), mainly due<br>
to the overflow issue. MPI really shouldn't adopt C's semantic model in<br>
any interface that might force other languages to choose between their<br>
own semantic model and C's, especially because MPI is being increasingly<br>
considered as an interface in other languages.<br>
<br>
Lastly, even C99 has not been generally accepted by the IT community,<br>
especially outside the USA. While <stdint.h> is one of the more widely<br>
implemented aspects of it, I don't know anyone who has checked how<br>
precisely the whole range of implementations adhere to the standard.<br>
Also, there is a new C standard being worked on, and there was a<br>
proposal to rewrite the specification of integer types and <stdint.h>,<br>
incompatibly; that is certainly in abeyance, and may have been rejected<br>
in toto, but I haven't checked the draft with a fine-tooth comb.<br>
<br>
Regards,<br>
Nick Maclaren.<br>
<br>
</font>
</p>
</div>
</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: 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; "><div><br class="Apple-interchange-newline">-- </div><div>Jeff Squyres</div><div><a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a></div></span>
</div>
<br></body></html>