"John S. Dyson" <dy...@iquest.net> writes: > I just wanted to "chime in" and say that the new patches are based > on a really good concept, and is much cleaner than the previous > method. Also, many RISC architectures can utilize this > method due to the availability of lots of general registers. > (One could go so far as to have the compiler reserve the > register.) Non-threaded user mode apps could optionally > use the reserved register, but for threaded user mode apps, > that reserved register could also be used as a per-thread > base pointer.
Reserving an arbitrary register can make binary compatibility with other systems more difficult. On the i386 it isn't bad since only a few horribly machine-dependent programs might use %fs for anything. Something to look at as a precedent for other processors should be what commercial Unix systems on various non-i386 processors do. > I believe that NT does the above (%fs for X86, and general > register for Alpha.) On PPC, there are several local, Digital UNIX does not reserve a register. Based on a quick check it would seem to be using a call to PALcode to find the thread-specific data. Note that this is nothing like a system call, it's much faster (something like 10 clocks). > per-processor registers that one could use (but loading a > general register with that per processor register would be > needed for access.) Also, since the PPC has lots of registers, > one could? permanently reserve one of the general registers (r13?). I really don't like the idea of breaking the normal language conventions for any processor. For the i386, the use of segment registers is not relevant to C language conventions, but reserving a general register on any architecture should, IMHO, be avoided if at all possible. > All in all, this change has the potential for better context > switching time (and less memory/better performance for multi-threaded I believe that having meaningful values context-switched in segment registers can add context switch overhead. It shouldn't be significant, though. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
