|[19 earlier articles]|
|Re: Integers on 64-bit machines firstname.lastname@example.org (Tony Finch) (2007-07-09)|
|Re: Integers on 64-bit machines email@example.com (Marco van de Voort) (2007-07-10)|
|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 firstname.lastname@example.org (napi) (2007-07-13)|
|Re: Integers on 64-bit machines email@example.com (Stefan Monnier) (2007-07-14)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (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 email@example.com (George Neuner) (2007-07-19)|
|From:||George Neuner <firstname.lastname@example.org>|
|Date:||Mon, 16 Jul 2007 03:09:16 -0400|
|References:||07-07-007 07-07-014 07-07-017 07-07-026 07-07-037 07-07-050|
On Fri, 13 Jul 2007 11:57:04 +0200, Hans-Peter Diettrich
>George Neuner wrote:
>> Actually, the integer compare instructions on many CPUs correctly
>> handles the n+1 bit result,
>You mean the overflow and carry flags? These flags contain meaninful
>values only after a comparison of arguments of the same signedness.
>Typically the *following* instructions determine the *interpretation* of
>the comparison result, as either a comparison of two signed or two
Only partly. What I mean is that, at the assembler level, the compare
and subtraction instructions are not necessarily interchangeable.
There are ISAs where some or all of the arithmetic instructions do not
set any condition codes and others in which add/subtract only indicate
a carry or borrow occurred. On such machines, the result can be
tested for zero and sign, but overflow information is lost. However,
the compare instruction generally correctly indicates when an overflow
occurs in the intrinsic subtraction.
There are ISAs which make multiword arithmetic very expensive because
propagating the carry/borrow correctly requires several instructions.
>> but a compiler may choose instead to use
>> subtraction and not catch the over/underflow.
>When the language allows for such behaviour...
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?
For ISAs where compare and subtract both set condition codes in the
same way, or in which condition codes are not exposed but compare
produces a signed value in a register, compare and subtract are
interchangeable when a value needs to be produced (such as for a
boolean store). Even if subtract does not produce exactly the same
conditions as compare, the compiler may use the subtraction form
anyway because the arithmetic result of the subtraction will be
Return to the
Search the comp.compilers archives again.