Mon, 16 Jul 2007 03:09:16 -0400

Related articles |
---|

[19 earlier articles] |

Re: Integers on 64-bit machines dot@dotat.at (Tony Finch) (2007-07-09) |

Re: Integers on 64-bit machines marcov@stack.nl (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 napi@axiomsol.com (napi) (2007-07-13) |

Re: Integers on 64-bit machines monnier@iro.umontreal.ca (Stefan Monnier) (2007-07-14) |

Re: Integers on 64-bit machines gneuner2@comcast.net (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 gneuner2@comcast.net (George Neuner) (2007-07-19) |

From: | George Neuner <gneuner2@comcast.net> |

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 |

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

<DrDiettrich1@aol.com> 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

needed.

George

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.