Subject: Re: [ub] [c++std-ext-14555] Sized integer types and char bits
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2013-10-20 06:18:10
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:
Table 41. 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:
Now if you read the Java documentation:
"Virtual Machine for the Java Platform on ClearPath OS 2200 JProcessor
8.5. JNI Transition Data Conversions
The Java language explicitly defines its numerical data types to very
specific formats and sizes:
- 8-bit 2s complement signed byte
- 16-bit 2s complement signed short
- 32-bit 2s complement signed integer
- 64-bit 2s 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 1s complement signed char
- 18-bit 1s complement short
- 36-bit 1s complement integer and long
- 72-bit 1s 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 1s complement to
and from 2complement 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
They seem to support COBOL, FORTRAN, C, Java and PLUS programming
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.
SG12 list run by herb.sutter at gmail.com