[Top] [All Lists]

Re: Coprocessors other than 1

To: "Kevin D. Kissell" <>
Subject: Re: Coprocessors other than 1
From: Ralf Baechle <>
Date: Sun, 9 Sep 2001 00:09:09 +0200
In-reply-to: <007b01c1387d$27e6f740$0deca8c0@Ulysses>; from on Sat, Sep 08, 2001 at 05:44:22PM +0200
References: <> <007b01c1387d$27e6f740$0deca8c0@Ulysses>
User-agent: Mutt/1.2.5i
On Sat, Sep 08, 2001 at 05:44:22PM +0200, Kevin D. Kissell wrote:

> > Skip over copX instructions for X != 1 also.
> I'm sure there's a story behind this of which I am not aware,
> but surely skippling COP2 or COP3 instructions can't be
> correct behavior.  Either there is no such coprocessor, in
> which case SIGILL would seem to me to be appropriate,
> or there really is some application-specific coprocessor
> on the COP2 interface.  If such a coprocessor exists, and
> has context that the kernel doesn't know how to save and
> restore, until such time as we develop kernel modules to
> handle them, wouldn't it be more practical to allow exactly
> one processor to "own" the coprocessor?  In that model,
> the first thread to issue a COP2 instruction would get it
> enabled and restart the instruction, but until that thread
> terminates, all other requestors would get nailed with
> SIGILL or some more appopriate signal.

Before this change the situation when we were trying to execute a copX
instruction (where X != 1) we would have re-executed the same instruction
again after returning from the signal handler / exception handler, ad

As for cop 0 this is the right thing to do because we treat it as
non-existant for userspace.  To my knowledge only Sony Playstation
implements coprocessor 2 (and we don't support it) and cop3 is afaik unused
except MIPS IV recycling it, so I think we do the right thing.


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