On Sat, 7 Apr 2001, Florian Lohoff wrote:
> > You are right, of course. That's why glibc contains two versions of
> > _test_and_set() code. If compiled for MIPS I, glibc uses a syscall
> > (currently sysmips()), while for MIPS II and higher it uses inline
> > assembly code which makes use of LL/SC.
> > That's exactly the way glibc does CPU-model-specific code for other
> > archs.
> The problem is that it is compile time - I would like to have
> a runtime version - Just export the existance of ll/sc to
> userspace somewhow.
I can't see any problem. If you want to go for speed -- compile glibc
for MIPS II (assuming you have a MIPS II or better CPU). If you want to
go for compatibility -- compile glibc for MIPS I (it will still run on
MIPS II or better CPUs, although suboptimally; actually, it won't be the
worst suboptimality then).
Similarly -- an Alpha EV56-compiled glibc will not run on an EV4 CPU,
while an EV4-compiled glibc will run on an EV56 CPU, although
> > I don't like run-time detection either. The compile-time choice is
> > sufficient enough. The _test_and_set() library function already hides
> > implementation details from the user.
> It isnt sufficent as we need a glibc beeing able to run on old
> decstations AND on newer machines like the Lasat machine
> which has an R5000.
A MIPS-I-compiled glibc will run on any MIPS CPU, using a kernel
_test_and_set() emulation (how kernel emulates _test_and_set() is not the
point here -- it has to be done in an MP-safe way, if necessary; LL/SC is
the most likely candidate for MIPS II or better kernels). A
MIPS-II-compiled glibc will run on any MIPS II or better CPU using LL/SC
directly. Similar for MIPS-III-compiled glibc, etc.
A MIPS-II-compiled kernel will still provide a _test_and_set() emulation
to keep the ABI consistent (e.g. for statically linked MIPS I binaries).
Still any problems? I will happily clarify any remaining issues.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: firstname.lastname@example.org, PGP key available +