Numeric comparisons

[Doug Pardee]

me >Fortunately, the more modern CPU chips are designed with a proper
me >compare instruction which does bit-wise comparison instead of
me >subtraction.
 
> 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 so; my apologies for not having been clear enough.  A proper compare
consists of determining the most significant bit which differs between
the two words, if any, and setting the result accordingly.  If it is the
Most Significant Bit that differs, then the result is inverted for
signed comparisons.

A usable approximation is to do a subtraction, but for signed
comparisons also do a sign-bit test.  If the sign bits do not match,
then the result is not equal, and the positive number is larger,
regardless of the result of the subtraction.

> The conditions used for the branch will determine how the operands are
> to be compared:  whether as signed integers or unsigned integers.  A
> subtraction sets 4 bits:  negative (N), zero (Z), carry (C), and
> overflow (V).  They are combined to indicate ordering relationships as
> follows:
> 
> signed <		N ^ V

This is great for CPUs such as the AMD bit-slice stuff which does
provide a "Negative XOR Overflow" status.  But for garden-variety
single-chip CPUs, this isn't the case.  On a Z-80, one must code
  JP    PE,OFLOWD
  JP    N,LT
  JP    GE
OFLOWD:
  JP    N,GE
  JP    Z,GE
  JP    LT

You don't get a choice on the Z-80.  But why subject yourself to this
on say, a 68000 when you could use CMP instead of SUB?
-- 
Doug Pardee -- CalComp -- {calcom1,savax,seismo,decvax,ihnp4}!terak!doug