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 Java™ 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=739&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