Florian Lohoff wrote:
On Wed, May 23, 2001 at 08:54:12PM +0200, Florian Lohoff wrote:
My favourit would be to let the glibc on runtime decide whether
to use sysmips or ll/sc in the atomic test_and_set stuff. This would
lead to an common atom op in the userspace which is fast on ll/sc
cpus and gives much lesser performance penaltys in the sysmips case
than emulating ll/sc.
But again - I tried to run this discussion again and again - As long
as there is no code to use there is no point in taking a discussion.
I needed a working sysmips for debian as we compile the glibc with
sysmips (performance penalty but for now works everywhere) thus
i fixed the sysmips.
I have to agree with the pragmatism first, philosophy second approach. If it is
beautiful but doesn't work it dosn't help anyone.
The thing I don't understand is how glibc is going to cleanly decide at
runtime which code to use. It's relatively easy to do something like
that in the kernel, but I can't come up with an elegant solution to make
such a choice at runtime in glibc.
Assuming that we're moving forward (as Kevin points out) the percentage
of systems without ll/sc is going down. While these systems don't have
much CPU power to spare, we should make the baseline implementation have
ll/sc emulation. If somebody wants to make a MIPS I optimized glibc,
then that's fine, but allowing the 'standard' MIPSII glibc to work on
all systems simplifies life ( mine at least ;) ).
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839