🚀 go-pugleaf

branch prediction usually works if we know where we are going to branch to.
About 80%(?) of predictable branches occur in loops, so why don't we just
implement loops?

The major problems with loops is the provision for compiler support but
the most common branch prediction technique( prediction bits) also need
compiler support.

We can remove any need for loops if we use loop-unrolling but we can also
remove any need for branch prediction if we do branch-rolling, the trade-off
being more code to be stored. So both techniques are just ways of reducing
code size without making any significant processing power improvement.

I'm more in favour of using loops because they are easier to implement in
hardware and very useful for my target application-signal processing.

Brach cache will be able to handle the more unpredictable (the 20% conditional
branch cases) but it will incur more hardware support. The advantage is that it
can handle more branch cases but is it worth the trouble? Shouldn't loops be
sufficient?
	Can we adopt the loop technique(special case jump hardware) for the
other cases? We can do that if we can identify the special branch cases.

Once the conditional branches become more frequent(80%) as the case for 
super-intelligent software, should we abandon pipelining altogether?
After all the branch-prediction techniques are designed to reduce pipeline
flush penalty. 

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet