Xref: utzoo comp.lang.c:32482 comp.arch:18370 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!portal!cup.portal.com!Don_A_Corbitt From: Don_A_Corbitt@cup.portal.com Newsgroups: comp.lang.c,comp.arch Subject: Re: a style question Message-ID: <34469@cup.portal.com> Date: 2 Oct 90 23:45:55 GMT References: <7341@darkstar.ucsc.edu> <1990Sep30.050655.13212@zoo.toronto.edu> <1990Sep30.172917.2951@Neon.Stanford.EDU> <1990Oct2.151644.1581@phri.nyu.edu> Organization: The Portal System (TM) Lines: 37 roy@phri.nyu.edu writes: > davis@pacific.mps.ohio-state.edu (John E. Davis) writes: > > Which ['x != 100' or 'x < 100' RHS] generates faster code? It seems to > > me that it is easier to tell if two values are unequal than to tell if > > one is greater than the other. I'd rather save the machine a few > > micro-seconds than myself since I only do the comparison once whereas the > > machine must do it many times. > > Are there actually any machines in which a compare-and-branch for > inequality is any faster or slower than a compare-and-branch for less-than? > It seems to me that either should take one pass through the ALU to do the > comparison and set some flags, so they should both take the same amount of > time. I'm basing my assumption on experience with pdp-11 type machines, > but I find it hard to imagine any other machine being significantly > different. Maybe if you had an asynchronous ALU? [goes on to theorize about RISC machine with limited branch types] Actually, the i860 is faster when comparing for equality than greater-than. For example: xor r16, r17, r0 bc somewhere takes two clocks, plus one annulled after the branch if taken. The sequence subu r16, r17, r0 bc somewhere takes three clocks, since there is a freeze before the conditional branch while the condition code is updated. On this chip, adds/addu and subs/subu followed by a conditional branch costs an extra cycle. 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. --- Don_A_Corbitt@cup.portal.com Not a spokesperson for CrystalGraphics, Inc. Mail flames, post apologies. Support short .signatures, three lines max. (Soon leaving this account - flame me now, while you have the chance!)