Re: Integers on 64-bit machines

On Thu, 19 Jul 2007 08:29:15 +0200, Hans-Peter Diettrich
<DrDiettrich1@aol.com> wrote:


>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
comparison.




>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
comparisons.




>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
>arithmetic.


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
mainly expository.


George

Return to the comp.compilers page.
Search the comp.compilers archives again.