Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!bbn!uwmcsd1!ig!agate!ucbvax!hplabs!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: conditional branches
Message-ID: <1573@winchester.mips.COM>
Date: 14 Feb 88 22:13:43 GMT
References: <191@telesoft.UUCP> <1556@gumby.mips.COM> <208@telesoft.UUCP>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 50

In article <208@telesoft.UUCP> roger@telesoft.UUCP (Roger Arnold @prodigal) writes:
>In article <1556@gumby.mips.COM>, earl@mips.COM (Earl Killian) writes:
>> Roger Arnold proposes [..] (boolean registers)

>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.  

It is difficult to do a general compare ( a < b ) and branch in one cycle,
without the effects noted.  If you're careful, you can do:
	register a = register b 
	register a != register b 
		compares against 0 fall out by using reg b == 0
	register a < 0  [i.e., sign bit == 1]
	register a >= 0 [sign bit == 0]
	register a > 0 [i.e., sign bit == 0, at least one nonzero bit elsewise]
	register a <= 0 [sign bit == 1, or sign == 0 and rest == 0]

>
>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.

Note also the difference between using a "compare" or "set" command that
sets one or bits in an arbitrary GP register, and a compare that sets
a real condition code register.  The former gives compilers much more latitude
for code scheduling, and actually turns out to simplify the hardware,
apparently: the "bypassing" hardware that lets you grab results in the next
instruction, before the results have actually gotten back to the registers,
is simpler because all it ever has to do is a uniformly-sized register,
not register + condition code.  [Probably not a huge deal, but every bit less
unnecessary complexity...]
Compilers do NOT like condition codes at all: a lot of very clean algorithms
get uglified by having to deal with magicly different condition-codes.
The restriction noted isn't particularly ugly: actually, it fit into
our scheme quite easily.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086