Thanks Ion, including for summarizing the key parts for us. This is very helpful!

Thanks,

Herb


> -----Original Message-----
> From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On
> Behalf Of Ion Gaztaņaga
> Sent: Sunday, October 20, 2013 4:18 AM
> To: WG21 UB study group
> Cc: C++ Std Ext
> Subject: Re: [ub] [c++std-ext-14555] Sized integer types and char bits
>
> El 19/10/2013 23:37, Herb Sutter wrote:
> > Ion wrote:
> >> For modern systems with CHAR_BIT != 8, please see:
> >
> > Thanks Ion, for the data about systems with >8 bit char.
> >
> > What about two's complement -- do we know systems that don't support
> it?
>
> All recent designs are two's complement, but as Jason has already said,
> Unisys still sells machines capable of executing Univac code. According to
> their website, those servers can execute Java and this requires two's
> complement, so I investigated a bit the issue. [note: similar features could be
> available in IBM mainframes, but maybe someone from IBM subscribed to
> the list might know real cases]
>
> According to ClearPath C compiler's manual:
>
> http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310422-011.pdf
>
> //////////////////////////////////
> //////////////////////////////////
>
> Table 4-1. Summary of Basic Data Types and Data Specifiers
>
> - char Represents an unsigned whole number in 9 bits.
> - unsigned char Represents an unsigned whole number in 9 bits.
> - signed char Represents a signed whole number in 9 bits.
> - int Represents a signed whole number in 36 bits.
> - signed int Represents a signed whole number in 36 bits.
> - unsigned int Represents an unsigned whole number in 36 bits.
> - short int Represents a signed whole number in 18 bits.
> - signed short int Represents a signed whole number in 18 bits.
> - unsigned short int Represents an unsigned whole number in 18 bits.
> - long int Represents a signed whole number in 36 bits.
> - signed long int Represents a signed whole number in 36 bits.
> - unsigned long int Represents an unsigned whole number in 36 bits.
> - long long int Represents a signed whole number in 72 bits.
> - signed long long int Represents a signed whole number in 72 bits.
> - float Represents a real number in 36 bits.
> - double Represents a real number in 72 bits.
> - long double Represents a real number in 72 bits.
>
> Integer Type Conversions
>
> UCS C represents an integer in 36-bit ones complement form (or 72-bit ones
> complement form, if the long long type attribute is specified).
> Unless the CONFORMANCE/ TWOSARITH keyword is used, there is no
> representation change when converting a signed int value to unsigned int or
> when converting an unsigned int value to signed int. For more information on
> the CONFORMANCE keyword, see the C Compiler Programming Reference
> Manual Volume 2.
>
> [You can find the second volume here:
> http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310430-016.pdf]
>
> //////////////////////////////////
> //////////////////////////////////
>
> Now if you read the Java documentation:
>
> "Virtual Machine for the JavaT Platform on ClearPath OS 2200 JProcessor
> [http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310430-016.pdf]
>
> //////////////////////////////////
> //////////////////////////////////
>
> 8.5. JNI Transition Data Conversions
>
> The Java language explicitly defines its numerical data types to very specific
> formats and sizes:
>
> - 8-bit 2's complement signed byte
> - 16-bit 2's complement signed short
> - 32-bit 2's complement signed integer
> - 64-bit 2's complement signed long
> - 32-bit IEEE 754 floating-point float
> - 64-bit IEEE 754 floating-point double
>
> Unfortunately, the Java data type definitions do not match or blend very well
> with the UCS C data types:
>
> - 9-bit 1's complement signed char
> - 18-bit 1's complement short
> - 36-bit 1's complement integer and long
> - 72-bit 1's complement long long (signed only)
> - 36-bit OS 2200 floating-point float
> - 72-bit OS 2200 floating-point double
>
> Since OS 2200 native C code expects parameters in native format and
> processes data in native format, the JProcessor JVM performs the
> appropriate data conversions at all transitions between Java code and native
> C code. When Java code calls native C code, the parameters are converted
> from Java format to OS 2200 native format. When native C code calls Java
> methods, the JProcessor JVM converts the parameters from native format to
> Java format. The JProcessor JVM also performs the appropriate conversions
> when the native C code calls JNI functions to get or set object data items or
> arrays.
>
> [...]
>
> 8.6 JNI Performance
>
> [...] On the ClearPath OS 2200 JProcessor, using Boolean arrays rather than
> Byte arrays will improve performance (this avoids 1's complement to and
> from 2'complement conversions on the calls)
>
> //////////////////////////////////
> //////////////////////////////////
>
> Note that CleaPath OS processors don't seem to have a C++ compiler (at
> least, it's not listed in "ClearPath OS 2200 Release 14.0. Application
> Development",
> http://public.support.unisys.com/search/DocumentationSearch.aspx?ID=73
> 9&pla=ps&nav=ps).
> They seem to support COBOL, FORTRAN, C, Java and PLUS programming
> languages only.
>
> C++ could require two's complement, but that would impose a performance
> penalty when processing signed integers in this platform.
>
> At least, it would be nice to have a macro to detect the representation
> of signed integers, so that we can portably dispatch low-level bit code
> to specific implementations (at at least assert when two's complement is
> the only supported representation). The same would be nice for padding
> bits, trap representations, floating point properties, etc.
>
> Best,
>
> Ion
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub