Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!pyramid!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: conditional branches
Message-ID: <7445@apple.UUCP>
Date: 19 Feb 88 18:30:03 GMT
References: <191@telesoft.UUCP> <1556@gumby.mips.COM> <375@imagine.PAWL.RPI.EDU> <1610@gumby.mips.COM> <4252@aw.sei.cmu.edu>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 46

In article <4252@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (Robert Firth) writes:
>Some of our work here confirms the view that condition codes are
>not a very good idea.
>	"The code generator slaves the condition codes
>	 religiously, both through linear code and across
>	 control transfers.  Nevertheless, of 415 conditional
>	 branches, 371 (almost 90%) required a prior test
>	 or compare to set the condition codes; of 2169
>	 normal instructions that set the condition codes,
>	 only 44 (about 2%) did so to any purpose.  It is
>	 hard to avoid the conclusion that condition codes
>	 are a waste of time, effort, and silicon."

(Here we go again...)  There is a paper by Robert D. Russell, "The PDP-11:
A Case Study of How _NOT_ To Design Condition Codes," that, although for
a different architecture, says exactly the same thing.  Excerpts from this
old, old paper:

"A sample of several hand-coded PDP-11 modules was taken at random from the
Oh my God------------^^^^^^^^^^
RSX-11M operating system, the DEC-10 communications front end (which is
handled by dedicated PDP-11s), and the PL-11 compiler.  These are typical
of "systems" programs found on the PDP-11.  Out of a total of 1044 assembled
instructions, 671 (64%) set the condition codes as a principle or side
effect of their operation.  Of these, only 159 (24%) were followed by
instruction sequences that actually utilized the condition code setting.
Hence, in 76% of the instructions the effort required to se the condition
codes was completely wasted.  Furthermore, of the 159 instructions that set
the condition codes for susequent meaningful utilization, 116 (73%) were
instructions (17 TST, 51 CMP, 42 BIT, 4 SEC, and 2 CLC instructions) whose
primary purpose is to set condition codes. ...  This means that the side
effect of setting the condition codes is wasted in 512 (92%) of the 555
instructions whose primary function is not condition code manipulation.
(Of the 43 that did set the condition codes for later use, 36 (84%) were MOV
instructions.)  Of course, these are measurements of "static" instruction
sequences, not a dynamic trace during execution.  Nonetheless, it would
appear that in practice very few explicit tests are eliminated by having
data operation instructions set the condition code bits as a side effect, 
and the increased complexity with accompanying performance degredataion of
having every such instruction set the condition codes is indeed not justified."

This paper was published sometime around 1975 (I can look up the reference
for interested parties).  This paper, together with optimizing compiler
papers and Wulf's "Compilers and Computer Architecture" and others
hammered home the point that condition codes are not the best way to
propagate relational information between instructions.