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