On Sun, Jan 20, 2002 at 12:58:00PM +0100, Kevin D. Kissell wrote: > > > I like the read-only k0 idea. We just need to make a system call to > > > tell kernel what value to put in k0 before returning to the user space. > > > It shouldn't be too hard to implement. I will try it next week. > > > > > > H.J. > > > > Please don't use k1, we already use k1 to implement fast > > test-and-set method for MIPS1 machine. We plan to mereg > > the method into main glibc and kernel tree. > > I don't read Japanese, but I've worked on similar > methods for semaphores using k1, so I can guess > roughly what you've done. We'll have to be very > careful if we want to have both a thread-register > extended ABI *and* this approach to semaphores. > The TLB miss handler must inevitably destroy one > or the other of k0/k1, though it can avoid destroying > both. Thus the merge of thread-register+semaphore > must not require that both be preserved on an > arbitrary memory reference. That may or may not > be possible, so it would be good if you guys at > Sony could post your code ASAP so we can see > what can and cannot be merged. As I understand, we don't need k1 based semaphore for MIPS II or above. So many processors can still benefit from the thread register. We can use a system call to implement loading a thread register. So it is a trade off between system-call/k1 for thread-register/semaphore. We can make it a configure time option. Since PS2 is already using k1 for semaphore, I'd like to see it get merged in ASAP so that anything we do won't break PS2. > > This situation also behooves us to verify that > k0/k1 are really and truly the only candidates > for a thread register in MIPS. I haven't been > involved in any of the earlier discussions, > and am not on the libc-hacker mailing list > (and thus cannot post to it, by the way), but You haven't missed anything. I changed it to the glibc alpha list. > was it considered to simply use one of the > static registers (say, s7/$23) in the existing > ABI? Assuming it was set up correctly at > process startup, it would be preserved by > pre-thread library and .o modules, and could > be exploited by newly generated code. Losing > a static register would be a hit on code generation > efficiency and performance, at least in principle. > Was this the reason why the idea was rejected, > or is there a more fundamental technical problem? We never considered it since it is an invasive ABI change. Besides the performance issue, it may break exist codes. I prefer k1 if all possible. H.J.
