[Top] [All Lists]

Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: "Maciej W. Rozycki" <>
Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: Joe deBlaquiere <>
Date: Wed, 23 May 2001 12:48:40 -0500
Cc: Jun Sun <>, Florian Lohoff <>,, Pete Popov <>, George Gensure <>,
References: <>
User-agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422
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.

Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

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