Path: utzoo!mnetor!uunet!husc6!think!ames!pasteur!ucbvax!dewey.soe.berkeley.edu!robinson From: robinson@dewey.soe.berkeley.edu (Michael Robinson) Newsgroups: comp.arch Subject: Re: conditional branches Message-ID: <23064@ucbvax.BERKELEY.EDU> Date: 20 Feb 88 03:33:02 GMT References: <191@telesoft.UUCP> <1556@gumby.mips.COM> <375@imagine.PAWL.RPI.EDU> <1610@gumby.mips.COM> <4252@aw.sei.cmu.edu> <7445@apple.UUCP> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: robinson@dewey.soe.berkeley.edu.UUCP (Michael Robinson) Organization: School of Education, UC-Berkeley Lines: 33 In article <7445@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >(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: >[...] >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.) But: >Of course, these are measurements of "static" instruction >sequences, not a dynamic trace during execution. Maybe I'm just stupid, but aren't the dynamic measurements far more significant? In my own assembly language programming, my experience has been that condition-code-setting instructions are used to advantage most often in tight, processor-intensive loops (copies, sorts, searches, etc.)--the type of instructions, therefore, that tend to get executed with much greater frequency than usual code. Surely, someone out there must have done dynamic analysis of condition code utilization. I won't be convinced on this issue until I've seen the results. ------------------------------------------------------------------------------ Michael Robinson USENET: ucbvax!ernie!robinson ARPA: robinson@ernie.berkeley.edu