Xref: utzoo comp.lang.c:32486 comp.arch:18372
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!leah!bingvaxu!kym
From: kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell)
Newsgroups: comp.lang.c,comp.arch
Subject: numeric comparison (was Re: a style question)
Message-ID: <4147@bingvaxu.cc.binghamton.edu>
Date: 3 Oct 90 04:07:13 GMT
References: <7341@darkstar.ucsc.edu> <1990Sep30.050655.13212@zoo.toronto.edu> <1990Sep30.172917.2951@Neon.Stanford.EDU> <DAVIS.90Oct1025438@pacific.mps.ohio-state.edu> <1990Oct2.151644.1581@phri.nyu.edu> <34469@cup.portal.com>
Reply-To: kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell)
Organization: SUNY Binghamton, NY
Lines: 17

In article <34469@cup.portal.com> Don_A_Corbitt@cup.portal.com writes:
>roy@phri.nyu.edu writes:
[equality comparison faster than greater]
>I haven't seen this in print, but I assume it is because there is extra 
>delay waiting for carry propagation to set the condition code.  XOR can
>test all the bits in parallel.

I think there is still O(log n) delays for all the bit XOR's to get
together into a final result. However, AND-ing together 32 XOR's is a 
much easier proposition than handling carry lookahead for the same number of
bits (assuming greater/less is done using effectively an ALU subtract).

The more efficient means of generating less/greater, comparable to
the the speed of XOR's for equality, are typically uneconomic to
implement in dedicated h/w.

-Kym Horsell