On 2008-01-29, Eric Smith <e...@brouhaha.com> wrote:
>>>>> to get all 1s, better is ~0
>>>> How is that better?
>>> should work on 1s-complement machines.
>
> CBFalconer <c...@yahoo.com> writes:
>> So does "unsigned int u = -1;".
>
> On a 1's complement machine, that will result in the variable
> u having all bits set other than the least signficant bit,
> since that is the one's complement representation of -1.

Are any of gcc's targets 1's compliment?

-- 
Grant Edwards                   grante             Yow!  I feel like a wet
                                  at               parking meter on Darvon!
                               visi.com            

On Jan 29, 4:31 am, Eric Smith <e...@brouhaha.com> wrote:
> Arlet Ottens <usene...@c-scape.nl> writes:
> > According to C99, 1's complement versus 2's complement, or even 'sign
> > and magnitude' notations only apply to _signed_ integer types.
>
> Sure.  So your -1 literal is a one's complement signed literal, represented
> with all bits one except the LSB.  Now you assign it to your unsigned
> variable, causing an implicit cast, and you still have the same bit pattern
> as your signed constant.

No. An implicit cast from signed to unsigned does not imply that the
bit pattern will be unchanged.

Section 6.3.1.3 from the C99 standard:

"2. Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type."

Eric Smith wrote:
>>>>>to get all 1s, better is ~0
>>>>
>>>>How is that better?
>>>
>>>should work on 1s-complement machines.
> 
> CBFalconer <c...@yahoo.com> writes:
> 
>>So does "unsigned int u = -1;".
> 
> On a 1's complement machine, that will result in the variable u having all
> bits set other than the least signficant bit, since that is the one's
> complement representation of -1.

That would be the case if you cast a bit pattern, as in
   *(int*) &u = -1;
If you just do
   u = -1;
you will always get 'all-bits-one', no matter what the actual
representation ist. At least, that's what the Holy Standard says in
6.3.1.3p2.


  Stefan

Grant Edwards <g...@visi.com> writes:
> Are any of gcc's targets 1's compliment?

Not that I've ever heard of.  Maybe someone has hacked it to target
a Unisys ClearPath (descendent of Univac 1107).

Stefan Reuther <s...@arcor.de> writes:
> That would be the case if you cast a bit pattern, as in
>    *(int*) &u = -1;
> If you just do
>    u = -1;
> you will always get 'all-bits-one', no matter what the actual
> representation ist. At least, that's what the Holy Standard says in
> 6.3.1.3p2.

I must be particuarly dense today, because I don't see how you get from
the wording of 6.3.1.3p2 to the conclusion that you're guaranteed that
assigning negative one to an unsigned variable guarantees that the latter
will have all bits set.

I wrote:
> I must be particuarly dense today, because I don't see how you get from
> the wording of 6.3.1.3p2 to the conclusion that you're guaranteed that
> assigning negative one to an unsigned variable guarantees that the latter
> will have all bits set.

Never mind, I see it now.

Whoever thought that up obviously never really considered what a compiler
for a one's complement machine would have to do to implement this:

    unsigned a;
    int b;
    [...]
    a = b;

to handle the case where b is negative at the time of the assignment.
(For the case of a literal or other static value, it can be dealt with
at compile time.)

The emitted code for the assignment will actually have to test for b being
negative and increment the representation.

Sigh.

Eric Smith wrote:

> Grant Edwards <g...@visi.com> writes:
> 
>>Are any of gcc's targets 1's compliment?
> 
> 
> Not that I've ever heard of.  Maybe someone has hacked it to target
> a Unisys ClearPath (descendent of Univac 1107).
> 

I don't have my old manuals handy; was the Unisys 10000 series
1's complement?

Michael

Eric Smith wrote:
> Stefan Reuther <s...@arcor.de> writes:
>> That would be the case if you cast a bit pattern, as in
>>    *(int*) &u = -1;
>> If you just do
>>    u = -1;
>> you will always get 'all-bits-one', no matter what the actual
>> representation ist. At least, that's what the Holy Standard says in
>> 6.3.1.3p2.
> 
> I must be particuarly dense today, because I don't see how you get from
> the wording of 6.3.1.3p2 to the conclusion that you're guaranteed that
> assigning negative one to an unsigned variable guarantees that the latter
> will have all bits set.

6.3.1.3p2 grants that the value you get will be the maximum value the 
unsigned type can hold, i.e.

	unsigned int u = -1;

yields UINT_MAX.  That's what you get by adding (UINT_MAX + 1) once to 
the input value of (-1), to arrive at a value inside the representable 
range of [0 ..UINT_MAX].

6.2.6.2 effectively defines that UINT_MAX must be of the form (2^n - 1), 
i.e. all-bits-one.  Well, "all-value-bits-one", to be fully picky.

Eric Smith wrote:

> Sure.  So your -1 literal is a one's complement signed literal, represented
> with all bits one except the LSB.  Now you assign it to your unsigned
> variable, causing an implicit cast, and you still have the same bit pattern
> as your signed constant.

No.  Casts are defined in terms of the _value_, not the representation.

> Sure.  But the implict cast doesn't change the representation, only the
> interpretation.  

It's exactly the other way round.

Eric Smith wrote:

> Whoever thought that up obviously never really considered what a compiler
> for a one's complement machine would have to do to implement this:

What do you base this belief on?  Are we to assume you're a telepathic 
time traveler, or how else would you know what people in a conference 
room did or didn't think, most of twenty years ago?

> The emitted code for the assignment will actually have to test for b being
> negative and increment the representation.

Yes.  So what?