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
pgph7sRdHaJKK.pgp
Description: PGP signature
|