Re: Integers on 64-bit machines

George Neuner <>
Mon, 16 Jul 2007 03:09:16 -0400

          From comp.compilers

Related articles
[19 earlier articles]
Re: Integers on 64-bit machines (Tony Finch) (2007-07-09)
Re: Integers on 64-bit machines (Marco van de Voort) (2007-07-10)
Re: Integers on 64-bit machines (Hans-Peter Diettrich) (2007-07-13)
Re: Integers on 64-bit machines (Chris F Clark) (2007-07-13)
Re: Integers on 64-bit machines (napi) (2007-07-13)
Re: Integers on 64-bit machines (Stefan Monnier) (2007-07-14)
Re: Integers on 64-bit machines (George Neuner) (2007-07-16)
Re: Integers on 64-bit machines (Hans-Peter Diettrich) (2007-07-19)
Re: Integers on 64-bit machines (George Neuner) (2007-07-19)
| List of all articles for this month |

From: George Neuner <>
Newsgroups: comp.compilers
Date: Mon, 16 Jul 2007 03:09:16 -0400
Organization: Compilers Central
References: 07-07-007 07-07-014 07-07-017 07-07-026 07-07-037 07-07-050
Keywords: arithmetic, storage
Posted-Date: 18 Jul 2007 20:04:15 EDT

On Fri, 13 Jul 2007 11:57:04 +0200, Hans-Peter Diettrich
<> wrote:

>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
>unsigned values.

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


Post a followup to this message

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