linux-mips
[Top] [All Lists]

Re: thread-ready ABIs

To: drepper@redhat.com
Subject: Re: thread-ready ABIs
From: Justin Carlson <justincarlson@cmu.edu>
Date: 18 Jan 2002 16:24:45 -0500
Cc: linux-mips@oss.sgi.com
Sender: owner-linux-mips@oss.sgi.com
For those of us who are slightly behind, could you give some brief
summary of what this thread register hullabaloo is about?  I hadn't been
following this thread, but a search of the archives makes it look like
it hasn't really been explained yet.

_Why_ do we need a general register which is read-only to userland?  Are
you trying to store thread-context information in a fast way?  Why does
this need to happen?

Depending on what the exact requirements are, I could see several ways
to free up a register:

We could, theoretically, free up k1 or k0 (but not both) at the expense
of some time in the stackframe setup at the userland/kernel boundary and
some time in the fast TLB handler.  This wouldn't be read-only from
userland, though, but is that really a hard requirement?  

There is precedent for hijacking some CP0 registers for purposes other
than originally intended, e.g., the WATCH registers for holding the
kernel stack pointer.  I don't have a mips spec in front of me, though,
so I don't know if any CP0 registers are readable from userland: I seem
to remember that all mfc0 ops are priveleged at the instruction level,
not the register level, though.

-Justin

Attachment: pgpR4m7RRLlCY.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>