|[21 earlier articles]|
|Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-13)|
|Re: Integers on 64-bit machines cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-13)|
|Re: Integers on 64-bit machines email@example.com (napi) (2007-07-13)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (Stefan Monnier) (2007-07-14)|
|Re: Integers on 64-bit machines email@example.com (George Neuner) (2007-07-16)|
|Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-19)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (George Neuner) (2007-07-19)|
|From:||George Neuner <email@example.com>|
|Date:||Thu, 19 Jul 2007 18:17:15 -0400|
|References:||07-07-007 07-07-014 07-07-017 07-07-026 07-07-037 07-07-050 07-07-064 07-07-071|
|Posted-Date:||19 Jul 2007 18:21:19 EDT|
On Thu, 19 Jul 2007 08:29:15 +0200, Hans-Peter Diettrich
>George Neuner wrote:
>> What compare generally tells you that subtract may not is whether the
>> corresponding arithmetic result is valid. Offhand, I can't think of
>> any example of an HLL where the semantics of comparison depend on that
>> particular difference. Anybody?
>A HLL comparison can return a perfectly valid True/False result,
>without an extra overflow case. That's different for a subtraction,
>where overflows can occur, and the language specification or
>implementation must specify the handling of this case.
My point was that the overflow occurs during compare as well during
subtraction and on some architectures only compare will tell you that
it did. As you correctly point out - overflow doesn't matter for
>IMO you missed my point.
Sorry if I did.
>On machines with a single compare
>instruction, different conditional jumps must be used for signed or
>unsigned compares, i.e. HLL ">" becomes either BHI or BGT. No such
>instructions or condition code settings exist for mixed sign
>operands. The same restrictions apply to other machine architectures,
>and to subtraction instead of comparison instructions.
Not necessarily. For machines that don't expose codes but simply
return a signed value in a register reflecting the result, the basic
six signed conditional jumps are sufficient for all uniform
>That's why a comparison or other arithmetic on mixed sign operands
>becomes more expensive than comparisons of operands of the same
>signedness, on every machine.
I believe comparing with mixed signage is usually a semantic mistake.
The unfortunate reality is that it happens to work approximately
99.999999976716935634613037109375% of the time and this lulls people
into thinking it is okay.
>In the case of true subranges (less bits required than a machine word
>can hold), the values can be stored as either signed or unsigned
>words, according to their signedness. Then all such values can be
>retrieved and interpreted as signed words, preventing mixed mode
At least within integer subranges. I haven't used a language with
real subranges for quite a while but I recall that pascal and
derivatives required deliberate ord() calls to compare enumerated
types, which structurally are also subranges.
>If you or somebody else disagrees, we better discuss the topic
>privately, and present the results to the group.
I don't think we have any real disagreement ... this exchange has been
Return to the
Search the comp.compilers archives again.