Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!gatech!hubcap!ncrcae!ncr-sd!crash!telesoft!roger
From: roger@telesoft.UUCP (Roger Arnold @prodigal)
Newsgroups: comp.arch
Subject: Re: conditional branches
Summary: is one cycle compare & branch feasible/desirable?
Message-ID: <208@telesoft.UUCP>
Date: 12 Feb 88 21:52:33 GMT
References: <191@telesoft.UUCP> <1556@gumby.mips.COM>
Organization: TeleSoft Inc., San Diego, CA
Lines: 42

In article <1556@gumby.mips.COM>, earl@mips.COM (Earl Killian) writes:
> Roger Arnold proposes [..] (boolean registers)
> 
> The problem with this is that it makes a conditional a two instruction
> sequence.  [..]  The abstract concept of "compare two values and
> branch accordingly" represents around 15% of the instructions executed
> on a computer.  To make this take two instructions increases your
> instruction count by 15% (and thus, in many cases, your cycle count by
> 15%).
> 
> [..] What I've found quite
> surprizing is that some recent architectures (e.g. Berkeley RISC and
> its clone, SPARC), used condition codes after studying instruction
> stream statistics.  I suppose compare and branch in one instruction
> was considered too difficult, at the time.

I'm no authority, but it doesn't surprise me at all that a RISC would
use condition codes.  Compare and branch, in one instruction, strikes 
me as more at home in a CISC than a RISC architecture.  For one thing, 
if the instruction cycle is closely tuned to the basic ALU cycle, there 
won't be time to feed back the result of a compare to the branch in one
cycle.  To allow it, the cycle would have to be extended, at a major
performance cost to the rest of the instruction set.  

Of course, marvelous things are possible with pipelining and parallel
lookahead, but there's still a second consideration: there aren't
enough bits to specify two operands and a target address in one fixed 
size instruction.  Not, at least, without imposing restrictions that do 
ugly things to the instuction set's orthogonality.  (E.g., both operands 
in a register, target address a limited displacement PC relative mode).  
Then, too, condition codes enable instruction scheduling; very good for 
pipelining and low level parallelism in top end hardware.

As to the 15% "compare two values" and branch, I've no trouble at all
believing that number.  In fact, it feels conservative, if it includes
comparisons to zero.  But it was consideration of how many of those
compaisions only repeat tests previously made that prompted me to 
suggest boolean registers.  Sorry, no numbers.  Just a programmer's 
notoriously unreliable "gut feeling", based on looking a LOT of code 
over the years.

- Roger Arnold				..ucsd!telesoft!roger