linux-mips-fnet
[Top] [All Lists]

Re: FP emulation patch available

To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Subject: Re: FP emulation patch available
From: "Kevin D. Kissell" <kevink@mips.com>
Date: Wed, 8 Mar 2000 21:12:49 +0100
Cc: "Linux SGI" <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>, <linux-mips@vger.rutgers.edu>
>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.


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