Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: delayed branch (& delayed loads!)
Message-ID: <33669@apple.Apple.COM>
Date: 2 Aug 89 17:28:49 GMT
References: <2246@taux01.UUCP> <1462@l.cc.purdue.edu> <26139@shemp.CS.UCLA.EDU>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 25

[]
>In article blahblahblah frazier@cs.ucla.edu (Greg Frazier) writes:
>
>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.

An interesting point to ponder is that delayed loads also have to schedule
something into their shadows, and they are (very roughly) as frequent as 
branches. Now, there are only so many instructions that can be re-arranged,
so it is possible that although branches shadows can be filled 70% of the time,
and load shadows can be filled 70% of the time, it may not be true that you can
fill both of the 70% of the time. Any comments from someone who has actually
measured this? It might be interesting to turn off filling of one, and see how
the percentage of filling the other increases.

--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum