Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ISM780.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!ISM780!marv
From: marv@ISM780.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: Numeric comparisons
Message-ID: <30000015@ISM780.UUCP>
Date: Fri, 27-Sep-85 17:02:00 EDT
Article-I.D.: ISM780.30000015
Posted: Fri Sep 27 17:02:00 1985
Date-Received: Mon, 30-Sep-85 02:44:30 EDT
References: <657@astrovax.UUCP>
Lines: 40
Nf-ID: #R:astrovax:-65700:ISM780:30000015:000:1320
Nf-From: ISM780!marv    Sep 27 17:02:00 1985


>What a bunch of BS!  A compare is simply a subtract with the result
>thrown away.  You imply that a compare does an exclusive-OR, which will
>compare only for equality, but not for ordering.

Not true for all machines!  There is a rather famous machine made by that
Itty Bitty Machine manufacturer that produces a condition code that is a
number in the range 0..2 (excuse a Pascal idiom in this form).

Quoting from the Princples of Operation for the machine:

     Compare

	Resulting condition code
	--------- --------- ----
	 0     Operands are equal
	 1     First operand is low
	 2     First operand is high
	 3     --


     Subtract

	Resulting condition code
	--------- --------- ----
	 0     Operands are equal
	 1     First operand is low
	 2     First operand is high
	 3     Overflow

The important point is that the compiler for this machine must generate more
code to compare two numbers if is uses a Subract instead of a Compare. Because
if (a-b) overflows the information about which operand is larger is not
preserved in the resulting condition code.

I just had to fix a bug in our C complier because it generated a Subtract
followed by a Branch Low (in the implementation of unsigned divide).  And in
a rather obscure case the subtraction caused an overflow.

	Marv Rubinstein -- Interactive Systems