Subject: Re: FP emulation patch available

From: "Kevin D. Kissell" <[email-masked]>
Date: Wed, 8 Mar 2000 21:12:49 +0100

>For the records (Sharp Mobilon HC-4500):
>
>Philips PR31700 (identical to Toshiba TMPR3912) @ 73.7 MHz, Implementation 0x22
>(same as R46[45]0), Revision 0x10 (does anybody know what R46[45]0 have?).
>
>Based on an R300A core with some ISA-II extensions, 1KB instruction cache, and
>4KB write-through data cache, 32 TLB entries.

If Philips/Tosh are really aliasing the PrID of the R4650, sombody has
done something Deeply Evil (and probably in violation of one agreement
or another).  I'm checking with MIPS HQ on this, and hoping that in fact
the R4650 value in the source code is in error.

If the Implementations *do* collide, we can still cope as long as the
revision codes do not.  The cpu_probe code first looks for a match
on Implementation+Revision, and then, that failing, looks for a match
on implementation alone.   So we could contrive to have 0x2210
resolve to CPU_R3900 and all other 0x22xx values to the R4650.
But I don't like it one bit.

>Back on topic:
>
>My Mobilon dies horribly with the screen going blank and even a soft reset
>doesn't revive it. All that helps is to remove all batteries. No error messages
>can be seen.
>
>My DS 5000/133 (R3000A) with FPU disabled and FPU emulation shows:
> Illegal instruction 00000034 at 801ce924, ...
>
>System.map shows:
> 801ce920 b dsemul_insns
> 801ce928 b dsemul_cpc
>
>Looks like your trick in mips_dsemul() doesn't work too well for ISA-I CPUs. Do
>you have an idea for an alternative?

Yes, and I should have thought of it earlier. The original Algorithmics
implementation, in fact, used the system call trap vector instead of the
Trap instruction vector to implement the trampoline for the delay slot
emulation.   Although I try to make sure that interrupts are disabled
during the operation, I was less than 100% confident that I could prevent
the Linux scheduler from executing, and stealing a seldom-used vector
seemed more prudent at the time.   In retrospect, I think I probably should
have generated an Address Error.  It'll be a pretty small hack - I'll see if I
can't turn it around this weekend.

FWIW, the current version of the emulator presumably might not have
paniced on you - I recently put the trampoline code on the user stack
where it belongs, so it can execute in user mode.   I haven't got around
to mentioning it on the web page, but you can find the patch on
ftp.paralogos.com in /pub/linux/mips/kernel with a fairly self-evident file
name.

            Kevin K.

---

From: Harald Koerfgen <[email-masked]>
Date: Thu, 09 Mar 2000 21:20:15 +0100 (MET)

Hi Kevin,

On 08-Mar-00 Kevin D. Kissell wrote:
[...]
> where it belongs, so it can execute in user mode.

Yes, but it would not have been so easy to find ;-)

> I haven't got around

Thanks, Kevin. I'll have a look at it.

-- 
Regards,
Harald

---

From: Warner Losh <[email-masked]>
Date: Wed, 08 Mar 2000 19:03:59 -0700

In message <[email-masked]> "Kevin D. Kissell" writes:
: If Philips/Tosh are really aliasing the PrID of the R4650, sombody has
: done something Deeply Evil (and probably in violation of one agreement
: or another).  I'm checking with MIPS HQ on this, and hoping that in fact
: the R4650 value in the source code is in error.

The R45650 is evil incarnate :-)  It doesn't have an MMU at all, so
maybe that's how you can tell the difference.

Warner

---

From: Warner Losh <[email-masked]>
Date: Wed, 08 Mar 2000 19:13:47 -0700

In message <[email-masked]> Dominic Sweetman writes:
: The R3900 should be 34 (decimal).  We don't have a record of the
: R4640/4650, which must surely be the same as each other.

My IDT79R46[45]0 RISC processor Hardware user's manual lists 0x22 as
on Page 4-10.  I don't have any software that will boot on the 4650
that I have, so I've not actually checked this.

I agree with your hobby horse :-)

Warner