[ub] [c++std-ext-14555] Sized integer types and char bits

Ion Gaztañaga igaztanaga at gmail.com
Sun Oct 20 13:18:10 CEST 2013


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


More information about the ub mailing list