Date: Wed, 30 Oct 2013 14:25:05 -0700
On 10/28/13, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
> On Oct 27, 2013, Lawrence Crowl <Lawrence_at_[hidden]> wrote:
>> On Oct 27, 2013, "Ion Gaztaņaga" <igaztanaga_at_[hidden]> wrote:
>>> I think requiring 2's complement in the long term would be a
>>> good idea, even in C, as no new architecture is using other
>>> representation and this simplifies teaching and programming in
>>> C/C++.
>>
>> Why do you think intN_t is not sufficient? The interpretation is
>> that int means "representation is not relevant, add traps if you
>> want" while (e.g.) int32_t means "I care about representation".
>
> Take the DSP with CHAR_BIT==24: int16_t doesn't exist, but
> int_least16_t does, and is 2's-complement and has no padding bits.
> Is there currently any way to express a demand for 2's-complement
> but not exact size on machines with large CHAR_BIT values?
I agree that you have a valid use case for which I do not think the
standard has a solution.
>>> that seems harder to emulate, and possibly less needed to
>>> allow programs to have portable behavior. If we have functions to
>>> serialize and deserialize as 2's-complement byte arrays, we may
>>> not need the ability to memcpy as them. 2's-complement behavior
>>> in conversions and bitwise operations may be enough.
>>
>> Unless we are going to make the radical step of making the built-in
>> integer types non-trivial, we get memcpy for free.
>
> memcpy is guaranteed to transfer values through byte arrays, but the
> values stored in the unsigned chars in the byte array aren't
> specified. Specifying a 2's-complement integer representation would
> seem to constrain the values in the unsigned chars making up the
> integer's object representation (even if order isn't guaranteed,
> popcount() would be), which is more than just specifying the results
> of shifts, bitwise operations, and conversions. I'm suggesting we
> consider the middle ground of avoiding implying a particular object
> representation.
Yes, we could require a one-to-one mapping between bits in the integer
and bits in the uchar array without specifying what that mapping is.
Users will then want a macro reporting the endianness. Unfortunately,
some systems were mixed endian. E.g., the PDP-11 had big-endian 16-bit
words, but stored 32-bit longs as little-endian sequences of words.
> On Oct 27, 2013, Lawrence Crowl <Lawrence_at_[hidden]> wrote:
>> On Oct 27, 2013, "Ion Gaztaņaga" <igaztanaga_at_[hidden]> wrote:
>>> I think requiring 2's complement in the long term would be a
>>> good idea, even in C, as no new architecture is using other
>>> representation and this simplifies teaching and programming in
>>> C/C++.
>>
>> Why do you think intN_t is not sufficient? The interpretation is
>> that int means "representation is not relevant, add traps if you
>> want" while (e.g.) int32_t means "I care about representation".
>
> Take the DSP with CHAR_BIT==24: int16_t doesn't exist, but
> int_least16_t does, and is 2's-complement and has no padding bits.
> Is there currently any way to express a demand for 2's-complement
> but not exact size on machines with large CHAR_BIT values?
I agree that you have a valid use case for which I do not think the
standard has a solution.
>>> that seems harder to emulate, and possibly less needed to
>>> allow programs to have portable behavior. If we have functions to
>>> serialize and deserialize as 2's-complement byte arrays, we may
>>> not need the ability to memcpy as them. 2's-complement behavior
>>> in conversions and bitwise operations may be enough.
>>
>> Unless we are going to make the radical step of making the built-in
>> integer types non-trivial, we get memcpy for free.
>
> memcpy is guaranteed to transfer values through byte arrays, but the
> values stored in the unsigned chars in the byte array aren't
> specified. Specifying a 2's-complement integer representation would
> seem to constrain the values in the unsigned chars making up the
> integer's object representation (even if order isn't guaranteed,
> popcount() would be), which is more than just specifying the results
> of shifts, bitwise operations, and conversions. I'm suggesting we
> consider the middle ground of avoiding implying a particular object
> representation.
Yes, we could require a one-to-one mapping between bits in the integer
and bits in the uchar array without specifying what that mapping is.
Users will then want a macro reporting the endianness. Unfortunately,
some systems were mixed endian. E.g., the PDP-11 had big-endian 16-bit
words, but stored 32-bit longs as little-endian sequences of words.
-- Lawrence Crowl
Received on 2013-10-30 22:25:08