Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!elroy.jpl.nasa.gov!ucla-cs!frazier
From: frazier@oahu.cs.ucla.edu (Greg Frazier)
Newsgroups: comp.arch
Subject: Re: delayed branch
Message-ID: <26139@shemp.CS.UCLA.EDU>
Date: 1 Aug 89 16:07:47 GMT
References: <2246@taux01.UUCP> <1462@l.cc.purdue.edu>
Sender: news@CS.UCLA.EDU
Reply-To: frazier@cs.ucla.edu (Greg Frazier)
Organization: UCLA Computer Science Department
Lines: 28

In article <1462@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
->In article <2246@taux01.UUCP>, cdddta@tasu76.UUCP (David Deitcher) writes:
->> branch target is being calculated. Does anyone have information as to
->> how often the compiler is able to put a useful instruction after the
->> branch as opposed to filling it with a NOP?
->
->This has nothing to do with the capabilities of the compiler, but I have
->often wanted to put one, or even several, instructions between a branch
->instruction and its execution.  As most problems have a substantial amount
->of order independence of operations, I would be surprised if a useful
->instruction could not be inserted in well over 90% of the cases.

Studies have shown (I love that phrase) that one delay can be filled
70% of the time, and a second 30% of the time (approx, of course).
There are two problems with filling delay slots.  The first is that
branches occur on the order of every 3 to 5 instructions - that's
a lot of slots to fill.  The second is that one often branches on
a value immediately after calculating it (i++; if i > 5 ...).  Oh,
you want a reference for those numbers?  The branch frequency comes
from some of the RISC papers from Berkeley (Patterson, et. al.).  I
think the slot filling numbers come from the same, but I'm not sure.

Greg
&&&&&&&&&&&&&&&&&&&&&@@@@@@@@@@@@@@@@@@@@@@######################
Greg Frazier	    o	Internet: frazier@CS.UCLA.EDU
CS dept., UCLA	   /\	UUCP: ...!{ucbvax,rutgers}!ucla-cs!frazier
	       ----^/----
		   /