Re: internal integer repres.

From: Dan Pop (Dan.Pop_at_cern.ch)
Date: 11/10/03 

Date: 10 Nov 2003 13:37:13 GMT

In <bom062$62q$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:

>Mantorok Redgormor <nethlek@tokyo.com> scribbled the following:
>> are all integers represented internally as just bit vectors?
>
>ISO C does not define how integers are represented internally.

If you were right, a Gray code-based implementation would be perfectly
conforming. Let's see if you're right:

     6.2.6.2 Integer types

1 For unsigned integer types other than unsigned char, the bits
     of the object representation shall be divided into two groups:
     value bits and padding bits (there need not be any of the
     latter). If there are N value bits, each bit shall represent
     a different power of 2 between 1 and 2**(N-1), so that objects of
     that type shall be capable of representing values from 0 to 2**N - 1
     using a pure binary representation; this shall be known as
     the value representation. The values of any padding bits are
     unspecified.44)

2 For signed integer types, the bits of the object representation
     shall be divided into three groups: value bits, padding bits,
     and the sign bit. There need not be any padding bits; there shall
     be exactly one sign bit. Each bit that is a value bit shall have
     the same value as the same bit in the object representation
     of the corresponding unsigned type (if there are M value bits
     in the signed type and N in the unsigned type, then M <= N).
     If the sign bit is zero, it shall not affect the resulting value.
     If the sign bit is one, the value shall be modified in one of
     the following ways:

     - the corresponding value with sign bit 0 is negated (sign
       and magnitude);

     - the sign bit has the value -(2**N) (two's complement);

     - the sign bit has the value -(2**N - 1) (one's complement).

     Which of these applies is implementation-defined, as is
     whether the value with sign bit 1 and all value bits zero
     (for the first two), or with sign bit and all value bits 1 (for
     one's complement), is a trap representation or a normal value.
     In the case of sign and magnitude and one's complement, if this
     representation is a normal value it is called a negative zero.

3 If the implementation supports negative zeros, they shall be
     generated only by:

     - the &, |, ^, ~, <<, and >> operators with arguments that
       produce such a value;

     - the +, -, *, /, and % operators where one argument is a negative
       zero and the result is zero;

     - compound assignment operators based on the above cases.

     It is unspecified whether these cases actually generate a
     negative zero or a normal zero, and whether a negative zero
     becomes a normal zero when stored in an object.

4 If the implementation does not support negative zeros, the
     behavior of the &, |, ^, ~, <<, and >> operators with arguments
     that would produce such a value is undefined.

5 The values of any padding bits are unspecified.45) A valid
     (non-trap) object representation of a signed integer type where
     the sign bit is zero is a valid object representation of the
     corresponding unsigned type, and shall represent the same value.

6 The precision of an integer type is the number of bits it uses
     to represent values, excluding any sign and padding bits. The
     width of an integer type is the same but including any sign bit;
     thus for unsigned integer types the two values are the same,
     while for signed integer types the width is one greater than
     the precision.

     ____________________

     44) Some combinations of padding bits might generate trap
         representations, for example, if one padding bit is a parity
         bit. Regardless, no arithmetic operation on valid values
         can generate a trap representation other than as part of an
         exceptional condition such as an overflow, and this cannot
         occur with unsigned types. All other combinations of padding
         bits are alternative object representations of the value
         specified by the value bits.

     45) Some combinations of padding bits might generate trap
         representations, for example, if one padding bit is a parity
         bit. Regardless, no arithmetic operation on valid values
         can generate a trap representation other than as part of
         an exceptional condition such as an overflow. All other
         combinations of padding bits are alternative object
         representations of the value specified by the value bits.

That's quite a lot of text about how integers are represented and,
incidentally, it rules out Gray coded integers...

Dan 

-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Relevant Pages

  • Re: A malloc question
    ... mention, have the same representation. ... integer types and all unsigned integer types act as if they ... The resulting tokens compose the controlling constant expression ... all signed integer types and all unsigned integer types act as ...
    (comp.lang.c)
  • Re: Any experience with "The Last One"?
    ... > "For unsigned integer types other than unsigned char, ... > shall be known as the value representation. ... representation of the corresponding unsigned integer types. ... that signed integer types be represented using a pure binary notation ...
    (comp.lang.c)
  • Re: Any experience with "The Last One"?
    ... > "For unsigned integer types other than unsigned char, ... > shall be known as the value representation. ...
    (comp.lang.c)
  • Re: Three questions about signed/unsigned type representations
    ... result that a true binary representation would. ... > integers will result in an invalid representation, ... The unsigned integer types are guaranteed safe under arithmetic, ... All unsigned integer types contain only value bits, ...
    (comp.lang.cpp)
  • Re: A malloc question
    ... all signed integer types and all unsigned integer types ... pointers, but I agree that all struct pointers have the same ... representation ...
    (comp.lang.c)