On Wed, 23 May 2001, Joe deBlaquiere wrote: > 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. The consensus was come to in January, IIRC. I should have coded an implementation long time ago, actually, but various events keep distracting me. > 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. There is a big advantage of invoking a single syscall vs faulting twice or more times on invalid opcodes. An the performance is an issue here -- wasting a few cycles may remain unnoticed on a decent system while it is extremely painful on slow systems. > 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. How often do you build glibc? For other programs it really doesn't matter which version of glibc you link against (given the same endianness). The linker does not fetch any code from shared objects when linking. Install binaries of glibc as appropriate but just choose any single copy of glibc for development. > 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 Well, do you really have an ISA I CPU which implements ll/sc? No? What about other missing instructions? Emulating instructions (as well as e.g. unaligned memory accesses) might be good for debugging, but for good performance you need to target your binaries to a specific system anyway. > 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 same is true for other processors. E.g. there is a noticeable performance advantage for certain code when compiled for the EV56 variation of Alpha (due to the BWX extension, i.e. instructions for byte- and halfword-wide memory accesses). Yet the resulting code does not run on an EV5 or EV4. You have to choose: either performance or compatibility. > 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 kernel gets adjusted at the build time. It's unrelated to the topic, though -- the syscall interface remains the same. > the problem over to glibc (and the toolchain) does increase the number > of active configurations. The same can be said of other platforms. For example, glibc built for i386 does not make use of i686's cmov instructions and is thus highly inefficient on such systems. So if you care of performance you choose an appropriate glibc build-time configuration which suits your system. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
