Re: Integers on 64-bit machines

On Thu, 19 Jul 2007 08:29:15 +0200, Hans-Peter Diettrich
<DrDiettrich1@xxxxxxx> 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
.

Relevant Pages

  • Re: Integers on 64-bit machines
    ... A HLL comparison can return a perfectly valid True/False result, ... and to subtraction instead of comparison instructions. ... That's why a comparison or other arithmetic on mixed sign operands ... words, according to their signedness. ...
    (comp.compilers)
  • Re: getbsize(3): Convert blocksizep to be unsigned long?
    ... Using unsigned values gives sign extension bugs and breaks overflow ... df and statfs() are good examples of the sign extension bugs. ... be type-generic modulo signedness, and would generate larger code (see the ...
    (freebsd-arch)