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
