Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mmintl.UUCP Path: utzoo!linus!philabs!pwa-b!mmintl!franka From: franka@mmintl.UUCP (Frank Adams) Newsgroups: net.lang.c Subject: Re: Numeric comparisons Message-ID: <688@mmintl.UUCP> Date: Mon, 23-Sep-85 20:12:41 EDT Article-I.D.: mmintl.688 Posted: Mon Sep 23 20:12:41 1985 Date-Received: Fri, 27-Sep-85 06:35:58 EDT References: <797@dataio.UUCP> <726@terak.UUCP> Reply-To: franka@mmintl.UUCP (Frank Adams) Organization: Multimate International, E. Hartford, CT Lines: 27 [Not food] In article <726@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes: >Fortunately, the more modern CPU chips are designed with a proper >compare instruction which does bit-wise comparison instead of >subtraction. All I ask is that the compiler writers *use* those >instructions the way they were intended, instead of substituting a >subtraction.(except carry) on subtraction, so the compiler writer is forced to use >the bit-wise compare instruction>. Many (most?) of those chips set the flags the same way after a subtract as after a compare. For that class of chips, a compare is a subtract with the correct flags set. Architectures where a branch cannot be taken based on a comparison of two signed numbers with two instructions (maybe three) are brain-damaged. It doesn't matter (much) whether the first instruction is a subtract or a compare. Compilers should generate a correct branch even on brain-damaged machines. Compilers for a machine where a compare and branch works, but a subtract and branch doesn't, but which use a subtract and branch, are *really* brain-damaged. Frank Adams ihpn4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108