NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/arch/11028

Internet Message Format | 1992-11-23 | 3.5 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!west.West.Sun.COM!male.EBay.Sun.COM!exodus.Eng.Sun.COM!flayout.Eng.Sun.COM!tremblay
From: [e-mail] (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 23 Nov 1992 17:52:26 GMT
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 50
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: flayout

In article <[e-mail]> [e-mail] (Torben AEgidius Mogensen) writes:
>If you can predict conditional branches, surely you can predict
>conditional moves and other conditional instructions as well, even
>using much the same techniques. In general any technique that can be
>used to optimize conditional branches can also be used to optimize
>other conditional instructions, so I can't see that using conditional
>instructions in general can ever be worse than using conditional
>branches only. One can then discuss how to reduce the penalty of
>having conditions only on branches.

Let me try to explain one more time what needs to be considered when
conditional moves and conditional branches are evaluated.

Conditional moves allow the program counter to progress sequentially.
Since the flow of instructions is unconditional (only the register file
update and the bypasses attached to the conditional move are conditional),
no repair is needed to correct the flow of instructions.
Usually conditional moves are used to eliminate conditional branches
that jump over a small piece of code. That is usually done by executing
*both* pieces of code (the part associated with the taken branch and the
one associated with the non-taken branch) simultaneously. By simultaneously
I mean in the same basic block (could be simultaneously in time on a
superscalar processor).

That works well if the number of instructions that are "guarded" is small,
since you may need to set up only one register, do a compare, and do a
single conditional move. If the number of instructions to guard is large,
then several instructions are needed to do the set up, several compares
may be needed (unless all instructions can be based on the original compare)
and several conditional moves are required. One can generalize and say
that in the "conditional move mode", twice as many instructions are needed,
reducing the throughput by one half. Clever tricks can be used, for example
using logical operations to merge both streams into one stream, but that
usually works only for small pieces of code. The throughput is not
reduced by one half for these, but it would certainly be degraded
significantly.

If conditional branches can be predicted accurately, then the break in the
flow of instructions can be hidden through a smart pre-fetcher (no magic here).
After the branch is executed, 100% of the hardware can be dedicated to
execute the correct path (versus ~50% for conditional moves). With a
smart processor front-end it would seem that it is always better to
use conditional branches, except that the prediction is not always correct
and a penalty of a few cycles is associated with the misprediction.
That is why the accuracy of the prediction and the efficiency of the
prefetcher is important when evaluating conditional moves vs.
conditional branches.

- Marc Tremblay.
Sun Microsystems.