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