Date: Fri, 8 Aug 2003 12:39:48 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: deischen@freebsd.org Cc: alpha@freebsd.org Subject: Re: Atomic swap Message-ID: <20030808023948.GU430@gsmx07.alcatel.com.au> In-Reply-To: <Pine.GSO.4.10.10308072201250.15156-100000@pcnet5.pcnet.com> References: <20030808015321.GB44639@dragon.nuxi.com> <Pine.GSO.4.10.10308072201250.15156-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-Aug-07 22:05:54 -0400, Daniel Eischen <eischen@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 following order: 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 some chips. Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030808023948.GU430>