Hi Maciej, Jun,
Didn't mean to bring up a sore point, but it seems that we haven't yet
come to a consensus on what policy to have here. I think you both make
valid points that I don't necesarily disagree with, but I would like to
follow the counterpoint a little further.
Maciej W. Rozycki wrote:
On Wed, 23 May 2001, Joe deBlaquiere wrote:
I would vote for option #4 - make sure the ll/sc emulation stuff works
and use ll/sc in glibc instead of sysmips. Beyond the pthreads mutex
Please don't. The emulation is an overkill here and the overhead is
painful for ISA I systems, which are usually not the fastest ones. This
has already been discussed here.
There's overhead to sysmips also, so neither one is going to give
stunning performance. All out performance isn't likely an issue on one
of these systems anyways.
If you want to go for speed and use ll/sc on an ISA II+ system, then
compile glibc for ISA II or better. It will never call sysmips() then.
The problem here is that now I have mips, mipsel, and mipselnollsc
configurations of the cross-tools, the c library and the binary
applications. It's one extra configuration to maintain.
There's no way to solve the endianness issues, but using emulation to
handle missing instructions (be they floating point or ll/sc, or
what-have-you) solves the minor differences in the instruction set from
the library/application standpoint. If all MIPS processors used the same
instruction set then we wouldn't have the problem at all. Of course
there are very good reasons (and probably some silly ones too...) why
ISAs are tailored.
The kernel is already going to have to adjust some anyway, so keeping the
differences in the kernel doesn't increase the testing burden. Throwing
the problem over to glibc (and the toolchain) does increase the number
of active configurations.
Just my opinion.
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839