peter.jeremy at alcatel.com.au
Thu Aug 7 19:39:54 PDT 2003
On 2003-Aug-07 22:05:54 -0400, Daniel Eischen <eischen at vigrid.com> wrote:
>On Thu, 7 Aug 2003, David O'Brien wrote:
>> On Thu, Aug 07, 2003 at 01:44:18PM -0400, Daniel Eischen wrote:
>> > "beq %1, 2f\n\t" /* if the store failed, spin */
>> It is worth explaining why this is "beq" since it wasn't obvious to all
>> readers. :-)
>Well, when you catch up on you're reading, you'll see the
>forward branch is no longer there. But FYI, it was
>supposedly there because it was thought that Alpha's
>always predicted a backwards branch, so the common
>case of the store succeeding wasn't optimized.
To clarify slightly: Originally, the Alpha architecture predicted
conditional branches based on the branch displacement - backward
branches were predicted taken and forward branches were predicted
not taken. Later Alpha versions will preferentially[*] use branch
history information stored in the Icache.
The latest AXP Architecture manual I have (Edition 4) states (A.2.2)
that branch prediction is implementation specific but infrequent cases
should be out-of-line (and out of cache if rare (<5%)). It further
recommends that the implementation strategy should prioritise in the
1) straight-line with no branch-takens
2) predict conditional branches based on the displacement (backward
taken, forward not-taken)
3) keep a prediction stack for subroutine return addressses.
The recommended code for atomic updates (5.5.2) still uses a forward
conditional branch for the store-failed case.
All the above said, the code should preferably include comments
explaining why the branch configuration was chosen. Whilst it's not
mandated by style(9), explaining why code is structured in a
particular way, rather than a different apparently simpler way is
generally a good idea.
[*] The branch prediction strategy is user selectable on at least
More information about the freebsd-alpha