On Wed, 23 May 2001, Jun Sun wrote: > Same old questions : Where is the definition of sysmips()? What is considered > standard implementation of sysmips() so that we can do reverse-engineering? > Irix? I think Ralf can comment it. > Even if Irix is considered standard implementation of sysmips(), I wonder if > we need to mirror it. Here is my reasoning. > > The sytem V ABI specifies _test_and_set() as the exntended system call. I think we want to execute IRIX binaries. The idea of providing sysmips() was to provide compatibility to other systems, AFAIK. I reused sysmips() for pthreads support in glibc as it was non-existent for ISA I CPUs and I needeed librt to run on my R3k. Much of discussion happened later and the conclusion was it's better to make a new call than to try to fiddle with sysmips(). I was not aware of the problems with sysmips() when I wrote the glibc code as sysmips() was nowhere defined and the interface seemed to be reasonable as implemented at that time. Later I was told sysmips(MIPS_ATOMIC_SET) is expected to return an error code which makes it incompatible to _test_and_set(). > Therefore, for MIPS I system, we simply choose to call sysmips(NEW_ATOMIC_SET, > ....) with three arguments. Any application that bypasses _test_and_set() and > calls sysmips() directly is running at its own risk of not being portable. Well, I now see using sysmips() for this purpose is ugly, it complicates immplementation a lot and hits performance of these slow systems where we want to save as many CPU cycles as possible. And still the problem of the error code remains. > Of course, we need to fix glibc, which seems to be the only client that > matters at this moment. That is not a problem, as I already stated. I'll see if I can cook the new syscall I'm writing of, soon. You'll see what I mean, then. > In short, I think we DON"T have to maitain the semantic of sysmips(). My > understanding is that it is justed used to implement extended MIPS ABS calls. Adding a new subfunction of sysmips() is not a problem. The cleanness on the code and the performance is. Note that other subfunctions of sysmips() are not performance-critical. The whole idea of sysmips() appears hackish to me. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
