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