Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!amdahl!dlb!dana!kck
From: kck@dana.UUCP (Ken Klingman)
Newsgroups: comp.arch
Subject: Re:  Branch prediction in the 532
Message-ID: <154@dana.UUCP>
Date: Thu, 23-Apr-87 21:01:53 EST
Article-I.D.: dana.154
Posted: Thu Apr 23 21:01:53 1987
Date-Received: Sat, 25-Apr-87 14:46:00 EST
References: <752@instable.UUCP>
Organization: Dana Computer, Inc., Sunnyvale, CA
Lines: 30

> 
> 2. Forward branches are predicted as not taken, backward branches are
>   predicted as taken, no matter who says otherwise. (We have tried
>   several methods of state machines, caches, etc. and found out that
>   this simple-minded method had the best ratio of relative performance
>   increase vs. cost in chip area and overhead.)
> -- 
> 	Amos Shapir

I kind of like the way branch prediction works on the Ridge 32 (and 3200)
architecture.  The conditional branch instructions have a branch predic-
tion bit.  If set, the instruction pre-fetch logic starts fetching from
the target of the branch; if not set, the pre-fetch logic continues
fetching along the same instruction stream.

This allows code generators and assembly language programmers to predict
whether or not branches will be/won't be taken.  In general the Ridge
compilers adopt the same philosophy of predict backward branches and don't
predict forward branches, but all the assembly coded library routines like
strcpy and friends make extensive use of it.

One iteresting possibility when the code generator has control over branch
prediction is how to predict if-then-else constructs.  Do you predict the
then and not predict the else?  Or do you predict the else and not the then?
Or maybe even more conterintuitively, maybe you predict/don't predict both?
I never had time to run an analysis to see which possibility was best.

Ken Klingman
Dana Computer
hplabs!dana!kck