At Wed, 2 Jan 2002 20:14:32 +0000 (UTC), "Wayne Knowles" wrote:
> setting MIPS3_SR_XX may not be necessary - if I am decoding the bits
> correctly it enables co-processor 3, which doesn't exist.

Take a look at e.g. page 246 of the R10K UM.

(google for t5.ver.2.0.book.pdf)

I believe the issue is that "MIPS IV", a.k.a. "cop1x" instructions
require that that be set at least on some processors (since their
encodings are in cp3 space).


Now, there are two issues here:

(1) I'm not sure what the n32 ABI says about using MIPS IV
    instructions.  (I.e., is it MIPS III, MIPS IV, or "not so well
    specified.")

(2) If it _does_ specify that MIPS IV instruction are allowed, then
    the code to enable MIPS IV instructions must be processor-specific
    (or at least, the bits to set in the SR must be set in a
    processor-specific way).

    On MIPS64, there are several interesting bits:

	PX (enables 64-bit instructions in user mode w/o 64-bit
	addressing)

	UX (64-bit instructions, plus 64-bit user segments and use of
	XTLB refill vector for user space references)

	SX, KX (64-bit supervisor/kernel segments, use of XTLB refill
	for references to supervisor/kernel space)

    MIPS64 reserves SR:CU3 for "future use by the Architecture."
    COP1X opcodes are controlled by the CU1 enable, and in general
    64-bit opcodes (see the mips64 spec for the definition of that)
    are controlled only by PX/UX as mentioned above.

    Offhand, I don't know whether it would be better to enable PX or
    UX for user mode in the current (32-bit VA) NetBSD/mips.

    (I guess the question is, do we care whether accesses go through
    the TLB miss vector or the XTLB miss vector?  Probably best to
    have all modes set up the same way, so the TLB miss handler is
    more likely to be in the cache...)


chris