🚀 go-pugleaf

In article <26139@shemp.CS.UCLA.EDU> 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.

	Note that a) branch frequency depends a lot on the architecture, and
also on the compiler's optimizer; b) slot-filling percentages (often taken
as a "universal" figure) depend highly on the instruction set of the machine,
and even the type of code being compiled.  In particular, 2-address instruction
machines are better at filling branches than 3-address machines (they're more
likely to have an instruction pair that can fill a 2-instruction delay, and
more likely to have pairs of instructions they can split up to fill branch and
load delays.

	One has to be careful about assumptions.  It's easy to take someone
else's research as being directly applicable to a different architecture, but
often it isn't, or is only partially applicable.

	The acid test is to simulate the damn thing with real code and
real compilers and gather real statistics.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"