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