[Top] [All Lists]

Re: Once again: test_and_set for CPUs w/o LL/SC

To: Johannes Stezenbach <>
Subject: Re: Once again: test_and_set for CPUs w/o LL/SC
From: "Maciej W. Rozycki" <>
Date: Wed, 16 Oct 2002 14:20:42 +0200 (MET DST)
Cc: "Kevin D. Kissell" <>,
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
Reply-to: "Maciej W. Rozycki" <>
On Tue, 15 Oct 2002, Johannes Stezenbach wrote:

> The ability to choose the implementation at run time sacrifices
> inlining, but has obvious performance benefits for the VR41XX-like
> platforms. It's also not a special MIPS thing,
> e.g. linuxthreads/sysdeps/<platform>/pt-machine.h has the
> used by e.g. i386.

 It also introduces an indirect call (jump?) overhead.  Anyway, you don't
need to sacrifice anything.  We may simply assume the universally
compatible way is the R3k one (be it sysmips() or whatever, if it gets
replaced).  Then there is the branch-likely way, which requires
branch-likely support (thus excludes R3k-class processors).  Then there is
the ll/sc way, which requires ll/sc (thus excludes R3k-class processors
and ones that lack the ll/sc instructions).  And you select the minimum
set of features required at the build time. 

> But all that is of interest only, if VR41XX-like platforms
> would use a glibc from a binary distribution like RedHat or
> Debian (I use Debian for development, but have a custom
> compiled glibc for production use).

 I wouldn't care of distributions -- if one really needs optimized
binaries it may make them be build somehow (either by doing the task
oneself or by convincing someone else).

> Yes, the kernel changes are not difficult. The difficulty was
> to find out the minimal necessary changes.

 You need to spot all kernel exit points.  Until we have R6k support it
means "eret" instructions. 

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>