Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!deimos.cis.ksu.edu!atanasoff!hascall
From: hascall@atanasoff.cs.iastate.edu (John Hascall)
Newsgroups: comp.arch
Subject: Re: Filling branch delay slot with test
Message-ID: <1437@atanasoff.cs.iastate.edu>
Date: 5 Sep 89 01:22:43 GMT
References: <1432@atanasoff.cs.iastate.edu> <26859@winchester.mips.COM>
Reply-To: hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall)
Distribution: na
Organization: Iowa State Univ. Computation Center
Lines: 38

In article <26859> mash@mips.COM (John Mashey) writes:
}In article <1432> hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) writes:
}
}>
}>         AGAIN:   JSUB   FOO_RTN        ; return FOO in R0
}>                  BEQL   AGAIN          ; try again if we
}>		  TEST   R0             ;   get zero back
}>		  JSUB   BAR_RTN        ; turn the FOO into a BAR
 
}>     Although not without complications, it would seem an
}>     excellent way to have a high branch delay slot fill ratio.
 
}The issue is doing the test far enough in advance of the conditional
}branch that the branch can use the results without stalls.

    I was thinking of doing it the other way around.

}Put another way: as much as computer architects would like
}pipestages whose results are available in advance of their execution,
}such things are only found in science-fiction......

     No.  What I was alluding to was "starting down both paths" of the
     branch and then "dumping the loser".

     One (simple minded?) way of doing this would be to have two
     parallel fetch&instruction-decoders in the pipe (perhaps with
     suitable memory interleaving).

     T     EXECUTE        F&I-D 1        F&I-D 2
     I     -------------  -------------  -------------
     M     BEQL AGAIN     TEST R0        -idle-
     E     TEST R0        JSUB BAR_RTN   JSUB FOO_RTN
     |     JSUB ???_RTN   ...            ...
     V


John Hascall
Signature void where prohibited by law.