This is the mail archive of the
mailing list for the glibc project.
Re: thread-ready ABIs
- From: "H . J . Lu" <hjl at lucon dot org>
- To: "Kevin D. Kissell" <kevink at mips dot com>
- Cc: Machida Hiroyuki <machida at sm dot sony dot co dot jp>, drepper at redhat dot com,GNU C Library <libc-alpha at sources dot redhat dot com>, linux-mips at oss dot sgi dot com
- Date: Sun, 20 Jan 2002 11:19:12 -0800
- Subject: Re: thread-ready ABIs
- References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020118201139.A847@lucon.org> <20020120193843M.firstname.lastname@example.org> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses>
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