Re: FP emulation patch available

Re: FP emulation patch available

[Kevin D. Kissell]

Herald Koerfgen writes:
>Personally, I don't have any idea why the emulator works perfectly on an
R3000
>but not on an R3912.

Nor I, but in the absence of data, I'm happy to speculate.  ;-)
...
>Oh I see, I should have made myself more clear. I have a root filesystem on
a
>CF card based on declinuxroot (a cut down RedHat 5.1) and my Mobilon boots
all
>the way through to the login prompt if I delete the fsck from the
initscripts.
>
>Booting into single user mode I can easily verify that tools like df or
e2fsck
>are bombing out with floating point exeptions. My "tests" with the emulator
>have been so far: Does df survive? What does fsck do? and things like that.
>Well, with the emulator all these tools make the Mobilon crash. Hard. So
hard
>that even the reset button doesn't work.


There are two ways in which the FPU emulator is close enough
to the hardware to be this sensitive to implementation.  One
is the way the emulator provokes an address error exception to
execute a delay slot instruction following a simulated branch, but
I don't think df or fsck do any branch-on-floating-conditions.  The
other is, of course, that it counts on getting sensible and recoverable
coprocessor unusable exceptions.  If the R3912 does something
funky to the processor state on a CP1 unusable fault - an event
that it doesn't have to deal with in its principal mission
as a Windows CE platform - the results would be much
what you are seeing.

There are people at Toshiba who read this mailing
list, so we can hope that they too are on the case and
can maybe lend a clue...

            Regards,

            Kevin K.

Re: FP emulation patch available

[Kevin D. Kissell]

Herald Koerfgen writes:
>Personally, I don't have any idea why the emulator works perfectly on an
R3000
>but not on an R3912.

Nor I, but in the absence of data, I'm happy to speculate.  ;-)
...
>Oh I see, I should have made myself more clear. I have a root filesystem on
a
>CF card based on declinuxroot (a cut down RedHat 5.1) and my Mobilon boots
all
>the way through to the login prompt if I delete the fsck from the
initscripts.
>
>Booting into single user mode I can easily verify that tools like df or
e2fsck
>are bombing out with floating point exeptions. My "tests" with the emulator
>have been so far: Does df survive? What does fsck do? and things like that.
>Well, with the emulator all these tools make the Mobilon crash. Hard. So
hard
>that even the reset button doesn't work.


There are two ways in which the FPU emulator is close enough
to the hardware to be this sensitive to implementation.  One
is the way the emulator provokes an address error exception to
execute a delay slot instruction following a simulated branch, but
I don't think df or fsck do any branch-on-floating-conditions.  The
other is, of course, that it counts on getting sensible and recoverable
coprocessor unusable exceptions.  If the R3912 does something
funky to the processor state on a CP1 unusable fault - an event
that it doesn't have to deal with in its principal mission
as a Windows CE platform - the results would be much
what you are seeing.

There are people at Toshiba who read this mailing
list, so we can hope that they too are on the case and
can maybe lend a clue...

            Regards,

            Kevin K.

Re: FP emulation patch available

[Harald Koerfgen]

On 13-Mar-00 Kevin D. Kissell wrote:

[FPU emulator crashes on R3912]

> There are two ways in which the FPU emulator is close enough
> to the hardware to be this sensitive to implementation.  One
> is the way the emulator provokes an address error exception to
> execute a delay slot instruction following a simulated branch, but
> I don't think df or fsck do any branch-on-floating-conditions.  The
> other is, of course, that it counts on getting sensible and recoverable
> coprocessor unusable exceptions.  If the R3912 does something
> funky to the processor state on a CP1 unusable fault - an event
> that it doesn't have to deal with in its principal mission
> as a Windows CE platform - the results would be much
> what you are seeing.

Good Point. Thanks, Kevin, I'll look deeper into that.

-- 
Regards,
Harald

Re: FP emulation patch available

[Kevin D. Kissell]

>> Denormalised operands (for example) will cause any computational
>> operation to blow up (change sign, load, store and move will survive -
>> can you think of much else?).  The requirement for MIPS hardware is
>> something like "you can throw an unimplemented exception in response
>> to any combination of operands and operation you don't like, so long
>> as it's rare".  That's why a complete emulator is probably a good
>> idea.
>>
>> Dominic Sweetman
>> dom@algor.co.uk
>
>OK, I'm convinced.  I believe I know how to make the Algorithmics
>emulator SMP-safe *and* more efficient in the general case, thanks
>in part to a suggestion from Ralf.  Time permitting, I will also wire it
>up to the unimplemented operation handler.  Give me a week or so
>to accumulate enough spare time...


OK, I've done it, and it seems to work very nicely indeed.
The combination of a real FPU with the Algorithmics emulator
for the Unimplemented corner case has given me the first
100% successful "paranoia" runs I've seen under MIPS Linux.
I also merged in some R3000 fixes that Harald pointed out
to me.  I'm holding off on distribution to give my colleagues
some time to merge in some CP0 hazard fixes, but we'll be 
putting the sources and patches up on the web in the next 
few days...

            Kevin K.

Re: FP emulation patch available

[Kevin D. Kissell]

>> Denormalised operands (for example) will cause any computational
>> operation to blow up (change sign, load, store and move will survive -
>> can you think of much else?).  The requirement for MIPS hardware is
>> something like "you can throw an unimplemented exception in response
>> to any combination of operands and operation you don't like, so long
>> as it's rare".  That's why a complete emulator is probably a good
>> idea.
>>
>> Dominic Sweetman
>> dom@algor.co.uk
>
>OK, I'm convinced.  I believe I know how to make the Algorithmics
>emulator SMP-safe *and* more efficient in the general case, thanks
>in part to a suggestion from Ralf.  Time permitting, I will also wire it
>up to the unimplemented operation handler.  Give me a week or so
>to accumulate enough spare time...


OK, I've done it, and it seems to work very nicely indeed.
The combination of a real FPU with the Algorithmics emulator
for the Unimplemented corner case has given me the first
100% successful "paranoia" runs I've seen under MIPS Linux.
I also merged in some R3000 fixes that Harald pointed out
to me.  I'm holding off on distribution to give my colleagues
some time to merge in some CP0 hazard fixes, but we'll be 
putting the sources and patches up on the web in the next 
few days...

            Kevin K.

Re: FP emulation patch available

[Kevin D. Kissell]

As Ralf just reminded me by email, the Algorithmics/MIPS
kernel FPU emulator is *not* SMP-safe.  It borrows an existing
(if seldom used) exception handler, and has only a single
set of emulated FPU registers.  I sort-of knew this, but
had not worried about it, since to the best of my knowledge
no one is building (or has built) SMP MIPS machines 
out of FPU-less processors.  Nevertheless, a compile-time
test, to blow up on any attempt at an SMP build of the 
emulator should always have been there, and is going in 
right away.

Does anyone out there actually need/want an SMP
version of the emulator?   It's not completely trivial,
but it would not be all that difficult to do...

            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

Re: FP emulation patch available

[Kevin D. Kissell]

As Ralf just reminded me by email, the Algorithmics/MIPS
kernel FPU emulator is *not* SMP-safe.  It borrows an existing
(if seldom used) exception handler, and has only a single
set of emulated FPU registers.  I sort-of knew this, but
had not worried about it, since to the best of my knowledge
no one is building (or has built) SMP MIPS machines 
out of FPU-less processors.  Nevertheless, a compile-time
test, to blow up on any attempt at an SMP build of the 
emulator should always have been there, and is going in 
right away.

Does anyone out there actually need/want an SMP
version of the emulator?   It's not completely trivial,
but it would not be all that difficult to do...

            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

Re: FP emulation patch available

[Alan Cox]

> Does anyone out there actually need/want an SMP
> version of the emulator?   It's not completely trivial,
> but it would not be all that difficult to do...

If you dont do it please add

#ifdef CONFIG_SMP
#error "Not on this emulator"
#endif

to the emu code - for the person who didnt know 8)

Re: FP emulation patch available

[Alan Cox]

> Does anyone out there actually need/want an SMP
> version of the emulator?   It's not completely trivial,
> but it would not be all that difficult to do...

If you dont do it please add

#ifdef CONFIG_SMP
#error "Not on this emulator"
#endif

to the emu code - for the person who didnt know 8)

Re: FP emulation patch available

[Harald Koerfgen]

On 13-Mar-00 Alan Cox wrote:
>> Does anyone out there actually need/want an SMP
>> version of the emulator?   It's not completely trivial,
>> but it would not be all that difficult to do...
> 
> If you dont do it please add
> 
>#ifdef CONFIG_SMP
>#error "Not on this emulator"
>#endif
> 
> to the emu code - for the person who didnt know 8)

harry:~ > grep CONFIG_SMP linux/arch/mips/config.in
harry:~ > grep CONFIG_SMP linux/arch/mips64/config.in
   bool '  Multi-Processing support (Experimental)' CONFIG_SMP

SCNR :-).
-- 
Regards,
Harald

Re: FP emulation patch available

[Harald Koerfgen]

On 13-Mar-00 Alan Cox wrote:
>> Does anyone out there actually need/want an SMP
>> version of the emulator?   It's not completely trivial,
>> but it would not be all that difficult to do...
> 
> If you dont do it please add
> 
>#ifdef CONFIG_SMP
>#error "Not on this emulator"
>#endif
> 
> to the emu code - for the person who didnt know 8)

harry:~ > grep CONFIG_SMP linux/arch/mips/config.in
harry:~ > grep CONFIG_SMP linux/arch/mips64/config.in
   bool '  Multi-Processing support (Experimental)' CONFIG_SMP

SCNR :-).
-- 
Regards,
Harald

Re: FP emulation patch available

[Ralf Baechle]

On Mon, Mar 13, 2000 at 09:33:02AM +0100, Kevin D. Kissell wrote:

> Does anyone out there actually need/want an SMP
> version of the emulator?   It's not completely trivial,
> but it would not be all that difficult to do...

It should be fixed if it's going to be used as the base for the kernel
fp support we need also for the Origins.

  Ralf

Re: FP emulation patch available

[William J. Earl]

Ralf Baechle writes:
 > On Mon, Mar 13, 2000 at 09:33:02AM +0100, Kevin D. Kissell wrote:
 > 
 > > Does anyone out there actually need/want an SMP
 > > version of the emulator?   It's not completely trivial,
 > > but it would not be all that difficult to do...
 > 
 > It should be fixed if it's going to be used as the base for the kernel
 > fp support we need also for the Origins.

      Yes, all MIPS CPUs with which I am familiar require at least some
kernel FP support for certain corner cases and workarounds.  

Re: FP emulation patch available

[Andrew R. Baker]

On Mon, 13 Mar 2000, Ralf Baechle wrote:
> On Mon, Mar 13, 2000 at 09:33:02AM +0100, Kevin D. Kissell wrote:
> 
> > Does anyone out there actually need/want an SMP
> > version of the emulator?   It's not completely trivial,
> > but it would not be all that difficult to do...
> 
> It should be fixed if it's going to be used as the base for the kernel
> fp support we need also for the Origins.

This should not be an issue for the design I am using for the hardware fp
support.  It will have a different entry point into the operation
emulation code that will use the hardware registers instead of the
software fpu struct.  It will also only handle operations that should
produce an unimplemented exception (this is not quite all of the fp ops).
Ralf, from discussing this with you earlier, this should be SMP safe, but
it should be checked anyway.  I will try and get some code out this week.

-Andrew

Re: FP emulation patch available

[Kevin D. Kissell]

Dominic Sweetman wrote:

> Andrew R. Baker (andrewb@uab.edu) writes:
>
> > ... It will also only handle operations that should produce an
> > unimplemented exception (this is not quite all of the fp ops).
>
> Denormalised operands (for example) will cause any computational
> operation to blow up (change sign, load, store and move will survive -
> can you think of much else?).  The requirement for MIPS hardware is
> something like "you can throw an unimplemented exception in response
> to any combination of operands and operation you don't like, so long
> as it's rare".  That's why a complete emulator is probably a good
> idea.
>
> Dominic Sweetman
> dom@algor.co.uk

OK, I'm convinced.  I believe I know how to make the Algorithmics
emulator SMP-safe *and* more efficient in the general case, thanks
in part to a suggestion from Ralf.  Time permitting, I will also wire it
up to the unimplemented operation handler.  Give me a week or so
to accumulate enough spare time...

Re: FP emulation patch available

[Kevin D. Kissell]

>After some minor patches it works fine on an R3000A (tested on a DECstation
>5000/133 with 2.3.47) but my Mobilon (R3912) still bombs out horribly.
>Unfortunately there is no fully functional serial driver for the R3912 yet so
>all I am able to tell is that this box crashes so badly that even the CPU
>internal LCD controller is going wild.
>
>Either there are more differences between an R3000 and an R3900 core as
>I am aware of (quite likely), or this may have something to do with the fact
that
>the R3912 definately has no FPU.

The R3900 is quite different in a number of details from the R3900A.
It has a different ISA (MIPS II+ instead of MIPS I), a different pipeline
and a different CP0 implementation.  And the R3912 has its rather
peculiar set of on-chip peripherals with, if memory serves, a somewhat
obnoxious memory map. Do you have a set of documentation for the
R3912?  I do, but I don't know when I will have time to check it against
the R3000 Linux code.

>Kevin, please forgive me this question, but has the Linux integration of
>the FPU emulation code been tested on MIPS CPUs without FPU?

Yes.  Of course.  What kind of amateur fire-and-forget hacker do you take
me for?!! ;-)   Specifically, we've run it on the MIPS 4Kc core.  Both big and
little endian.  We also ran it on R4400 Indys and R5260 Algorithmics platforms
with the FPUs disabled in software.  I'm not saying that it's perfect - I know
it cannot be - but the emulator does not get invoked until very late in the
boot process, just before init fires up, so if you're dieing early on, whatever
it is, it ain't the emulator, and it isn't the lack of FP.  Even without an
emulator, the 2.2.12 kernel will get as far as trying to run init on an FPU-less
machine.

            Regards,

            Kevin K.

Re: FP emulation patch available

[Kevin D. Kissell]

>After some minor patches it works fine on an R3000A (tested on a DECstation
>5000/133 with 2.3.47) but my Mobilon (R3912) still bombs out horribly.
>Unfortunately there is no fully functional serial driver for the R3912 yet so
>all I am able to tell is that this box crashes so badly that even the CPU
>internal LCD controller is going wild.
>
>Either there are more differences between an R3000 and an R3900 core as
>I am aware of (quite likely), or this may have something to do with the fact
that
>the R3912 definately has no FPU.

The R3900 is quite different in a number of details from the R3900A.
It has a different ISA (MIPS II+ instead of MIPS I), a different pipeline
and a different CP0 implementation.  And the R3912 has its rather
peculiar set of on-chip peripherals with, if memory serves, a somewhat
obnoxious memory map. Do you have a set of documentation for the
R3912?  I do, but I don't know when I will have time to check it against
the R3000 Linux code.

>Kevin, please forgive me this question, but has the Linux integration of
>the FPU emulation code been tested on MIPS CPUs without FPU?

Yes.  Of course.  What kind of amateur fire-and-forget hacker do you take
me for?!! ;-)   Specifically, we've run it on the MIPS 4Kc core.  Both big and
little endian.  We also ran it on R4400 Indys and R5260 Algorithmics platforms
with the FPUs disabled in software.  I'm not saying that it's perfect - I know
it cannot be - but the emulator does not get invoked until very late in the
boot process, just before init fires up, so if you're dieing early on, whatever
it is, it ain't the emulator, and it isn't the lack of FP.  Even without an
emulator, the 2.2.12 kernel will get as far as trying to run init on an FPU-less
machine.

            Regards,

            Kevin K.

Re: FP emulation patch available

[Harald Koerfgen]

On 12-Mar-00 Kevin D. Kissell wrote:
> The R3900 is quite different in a number of details from the R3900A.
> It has a different ISA (MIPS II+ instead of MIPS I), a different pipeline
> and a different CP0 implementation. And the R3912 has its rather
> peculiar set of on-chip peripherals with, if memory serves, a somewhat
> obnoxious memory map. Do you have a set of documentation for the
> R3912?  I do, but I don't know when I will have time to check it against
> the R3000 Linux code.

Yes, I have documentation for the R3912. In fact, if I am allowed to say
this, I wrote most of the R3000 and all of the R3912 code so far in Linux 8)
 
>>Kevin, please forgive me this question, but has the Linux integration of
>>the FPU emulation code been tested on MIPS CPUs without FPU?
> 
> Yes.  Of course.  What kind of amateur fire-and-forget hacker do you take
> me for?!! ;-)   Specifically, we've run it on the MIPS 4Kc core.  Both big
> and little endian.  We also ran it on R4400 Indys and R5260 Algorithmics
> platforms with the FPUs disabled in software. 

That's exactly what I am wondering about. Does it make a difference for the
emulator if the CPU has an FPU (disabled, obviously) or not?

Personally, I don't have any idea why the emulator works perfectly on an R3000
but not on an R3912.

> I'm not saying that it's perfect - I know it cannot be - but the emulator
> does not get invoked until very late in the boot process, just before init
> fires up, so if you're dieing early on, whatever it is, it ain't the
> emulator, and it isn't the lack of FP.  Even without an emulator, the
> 2.2.12 kernel will get as far as trying to run init on an FPU-less
> machine.

Oh I see, I should have made myself more clear. I have a root filesystem on a
CF card based on declinuxroot (a cut down RedHat 5.1) and my Mobilon boots all
the way through to the login prompt if I delete the fsck from the initscripts.

Booting into single user mode I can easily verify that tools like df or e2fsck
are bombing out with floating point exeptions. My "tests" with the emulator
have been so far: Does df survive? What does fsck do? and things like that.
Well, with the emulator all these tools make the Mobilon crash. Hard. So hard
that even the reset button doesn't work.

Anyway, it looks like we will going to have a fully functional serial driver
soon and that should make debugging somewhat easier.

-- 
Regards,
Harald

Re: FP emulation patch available

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

>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?


I have come up with a slightly-less-pretty hack that uses the
Load Address Error trap instead of the Trap instruction to force
kernel entry in the delay slot emulator. It seems just as functional
as the previous version (i.e. operational but "paranoia" finds an
exponentiation problem), and is currently being tortured with crashme
to see if it holds up under corrupted instruction streams and corrupted
process states.  I attach a pseudo-patch (cvs diff -c output) for the changes
relative to the version obtained by applying the previous patches on the
paralogos.com server, and would appreicate verification that it does
indeed work on an R3K.  If it does, I'll check it into the MIPS repository
and it will be included in the next web distribution (and maybe our
CD-ROMS).

My apologies to those of you whose mailers can't handle
attachments.

            Regards,

            Kevin K.



[-- Attachment #2: cp1emu.patch --]
[-- Type: application/octet-stream, Size: 3411 bytes --]

Index: cp1emu.c
===================================================================
RCS file: /home/repository/sw/linux-2.2.12/linux/arch/mips/fpu_emulator/cp1emu.c,v
retrieving revision 1.5
diff -c -r1.5 cp1emu.c
*** cp1emu.c	2000/02/27 15:19:18	1.5
--- cp1emu.c	2000/03/12 12:24:06
***************
*** 767,772 ****
--- 767,774 ----
  static unsigned int	dsemul_sr;
  static void *dsemul_osys;
  
+ #define AdEL 4
+ #define AdELOAD 0x8fa00001
  
  int
  do_dsemulret(struct pt_regs *xcp)
***************
*** 774,781 ****
  #ifdef DSEMUL_TRACE
      _mon_printf ("desemulret\n");
  #endif
!     /* Restore previous Trap instruction vector */
!     (void)set_except_vector(13, dsemul_osys);
      /* Set EPC to return to post-branch instruction */
      xcp->cp0_epc = VA_TO_REG (dsemul_cpc);
      /* 
--- 776,783 ----
  #ifdef DSEMUL_TRACE
      _mon_printf ("desemulret\n");
  #endif
!     /* Restore previous exception vector */
!     (void)set_except_vector(AdEL, dsemul_osys);
      /* Set EPC to return to post-branch instruction */
      xcp->cp0_epc = VA_TO_REG (dsemul_cpc);
      /* 
***************
*** 811,833 ****
       */
      dsemul_insns = (mips_instruction *)(xcp->regs[29] & ~3);
      dsemul_insns -= 3; /* Two instructions, plus one for luck ;-) */
!     /* Verify that space exists, or can be grown, on the stack */
      if(verify_area(VERIFY_WRITE, dsemul_insns, sizeof(mips_instruction)*2)) 
  	return SIGBUS;
      
      dsemul_insns[0] = ir;
      /* 
       * Algorithmics used a system call instruction, and
!      * borrowed that vector.  It seems more prudent, and
!      * is simpler in Linux, to use a TEQ instruction, though
!      * this does require a MIPS II CPU.
       */
- #define TEQ_R0_R0 0x00000034 
-     dsemul_insns[1] = TEQ_R0_R0;
  
      dsemul_cpc = cpc;
      dsemul_sr = xcp->cp0_status;
!     dsemul_osys = set_except_vector(13, handle_dsemulret);
   
      xcp->cp0_epc = VA_TO_REG &dsemul_insns[0];
      xcp->cp0_status &= ~ST0_IM;	/* interrupt disabled inside dsemul! */
--- 813,841 ----
       */
      dsemul_insns = (mips_instruction *)(xcp->regs[29] & ~3);
      dsemul_insns -= 3; /* Two instructions, plus one for luck ;-) */
!     /* Verify that the stack pointer is not competely insane */
      if(verify_area(VERIFY_WRITE, dsemul_insns, sizeof(mips_instruction)*2)) 
  	return SIGBUS;
      
      dsemul_insns[0] = ir;
      /* 
       * Algorithmics used a system call instruction, and
!      * borrowed that vector.  As that would be catastrophic
!      * if a reschedule happens, a TEQ instruction was used
!      * in early versions of the Linux kernel emulator, since 
!      * Linux does nothing useful with Trap instructions.
!      * That does not work on R3000s, however, so here we
!      * steal the Address Error on Load vector and
!      * generate an address error on an unaligned load.
       */
  
+     /* If one is *really* paranoid, one tests for a bad stack pointer */
+     if((xcp->regs[29] & 0x3) == 0x3) dsemul_insns[1] = AdELOAD - 1;
+     else dsemul_insns[1] = AdELOAD;
+ 
      dsemul_cpc = cpc;
      dsemul_sr = xcp->cp0_status;
!     dsemul_osys = set_except_vector(AdEL, handle_dsemulret);
   
      xcp->cp0_epc = VA_TO_REG &dsemul_insns[0];
      xcp->cp0_status &= ~ST0_IM;	/* interrupt disabled inside dsemul! */

Re: FP emulation patch available

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

>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?


I have come up with a slightly-less-pretty hack that uses the
Load Address Error trap instead of the Trap instruction to force
kernel entry in the delay slot emulator. It seems just as functional
as the previous version (i.e. operational but "paranoia" finds an
exponentiation problem), and is currently being tortured with crashme
to see if it holds up under corrupted instruction streams and corrupted
process states.  I attach a pseudo-patch (cvs diff -c output) for the changes
relative to the version obtained by applying the previous patches on the
paralogos.com server, and would appreicate verification that it does
indeed work on an R3K.  If it does, I'll check it into the MIPS repository
and it will be included in the next web distribution (and maybe our
CD-ROMS).

My apologies to those of you whose mailers can't handle
attachments.

            Regards,

            Kevin K.



[-- Attachment #2: cp1emu.patch --]
[-- Type: application/octet-stream, Size: 3411 bytes --]

Index: cp1emu.c
===================================================================
RCS file: /home/repository/sw/linux-2.2.12/linux/arch/mips/fpu_emulator/cp1emu.c,v
retrieving revision 1.5
diff -c -r1.5 cp1emu.c
*** cp1emu.c	2000/02/27 15:19:18	1.5
--- cp1emu.c	2000/03/12 12:24:06
***************
*** 767,772 ****
--- 767,774 ----
  static unsigned int	dsemul_sr;
  static void *dsemul_osys;
  
+ #define AdEL 4
+ #define AdELOAD 0x8fa00001
  
  int
  do_dsemulret(struct pt_regs *xcp)
***************
*** 774,781 ****
  #ifdef DSEMUL_TRACE
      _mon_printf ("desemulret\n");
  #endif
!     /* Restore previous Trap instruction vector */
!     (void)set_except_vector(13, dsemul_osys);
      /* Set EPC to return to post-branch instruction */
      xcp->cp0_epc = VA_TO_REG (dsemul_cpc);
      /* 
--- 776,783 ----
  #ifdef DSEMUL_TRACE
      _mon_printf ("desemulret\n");
  #endif
!     /* Restore previous exception vector */
!     (void)set_except_vector(AdEL, dsemul_osys);
      /* Set EPC to return to post-branch instruction */
      xcp->cp0_epc = VA_TO_REG (dsemul_cpc);
      /* 
***************
*** 811,833 ****
       */
      dsemul_insns = (mips_instruction *)(xcp->regs[29] & ~3);
      dsemul_insns -= 3; /* Two instructions, plus one for luck ;-) */
!     /* Verify that space exists, or can be grown, on the stack */
      if(verify_area(VERIFY_WRITE, dsemul_insns, sizeof(mips_instruction)*2)) 
  	return SIGBUS;
      
      dsemul_insns[0] = ir;
      /* 
       * Algorithmics used a system call instruction, and
!      * borrowed that vector.  It seems more prudent, and
!      * is simpler in Linux, to use a TEQ instruction, though
!      * this does require a MIPS II CPU.
       */
- #define TEQ_R0_R0 0x00000034 
-     dsemul_insns[1] = TEQ_R0_R0;
  
      dsemul_cpc = cpc;
      dsemul_sr = xcp->cp0_status;
!     dsemul_osys = set_except_vector(13, handle_dsemulret);
   
      xcp->cp0_epc = VA_TO_REG &dsemul_insns[0];
      xcp->cp0_status &= ~ST0_IM;	/* interrupt disabled inside dsemul! */
--- 813,841 ----
       */
      dsemul_insns = (mips_instruction *)(xcp->regs[29] & ~3);
      dsemul_insns -= 3; /* Two instructions, plus one for luck ;-) */
!     /* Verify that the stack pointer is not competely insane */
      if(verify_area(VERIFY_WRITE, dsemul_insns, sizeof(mips_instruction)*2)) 
  	return SIGBUS;
      
      dsemul_insns[0] = ir;
      /* 
       * Algorithmics used a system call instruction, and
!      * borrowed that vector.  As that would be catastrophic
!      * if a reschedule happens, a TEQ instruction was used
!      * in early versions of the Linux kernel emulator, since 
!      * Linux does nothing useful with Trap instructions.
!      * That does not work on R3000s, however, so here we
!      * steal the Address Error on Load vector and
!      * generate an address error on an unaligned load.
       */
  
+     /* If one is *really* paranoid, one tests for a bad stack pointer */
+     if((xcp->regs[29] & 0x3) == 0x3) dsemul_insns[1] = AdELOAD - 1;
+     else dsemul_insns[1] = AdELOAD;
+ 
      dsemul_cpc = cpc;
      dsemul_sr = xcp->cp0_status;
!     dsemul_osys = set_except_vector(AdEL, handle_dsemulret);
   
      xcp->cp0_epc = VA_TO_REG &dsemul_insns[0];
      xcp->cp0_status &= ~ST0_IM;	/* interrupt disabled inside dsemul! */

Re: FP emulation patch available

[Harald Koerfgen]

Hi Kevin,

On 12-Mar-00 Kevin D. Kissell wrote:
> I have come up with a slightly-less-pretty hack that uses the
> Load Address Error trap instead of the Trap instruction to force
> kernel entry in the delay slot emulator. It seems just as functional
> as the previous version (i.e. operational but "paranoia" finds an
> exponentiation problem), and is currently being tortured with crashme
> to see if it holds up under corrupted instruction streams and corrupted
> process states.  I attach a pseudo-patch (cvs diff -c output) for the changes
> relative to the version obtained by applying the previous patches on the
> paralogos.com server, and would appreicate verification that it does
> indeed work on an R3K.  If it does, I'll check it into the MIPS repository
> and it will be included in the next web distribution (and maybe our
> CD-ROMS).

After some minor patches it works fine on an R3000A (tested on a DECstation
5000/133 with 2.3.47) but my Mobilon (R3912) still bombs out horribly.
Unfortunately there is no fully functional serial driver for the R3912 yet so
all I am able to tell is that this box crashes so badly that even the CPU
internal LCD controller is going wild.

Either there are more differences between an R3000 and an R3900 core as I am
aware of (quite likely), or this may have something to do with the fact that the
R3912 definately has no FPU.

Kevin, please forgive me this question, but has the Linux integration of the FPU
emulation code been tested on MIPS CPUs without FPU?

-- 
Regards,
Harald

Re: FP emulation patch available

[Kevin D. Kissell]

>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.

Re: FP emulation patch available

[Kevin D. Kissell]

>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.

Re: FP emulation patch available

[Warner Losh]

In message <042401bf893a$b15465b0$0ceca8c0@satanas.mips.com> "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

Re: FP emulation patch available

[Warner Losh]

In message <200003082223.WAA00605@gladsmuir.algor.co.uk> 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

Re: FP emulation patch available

[Harald Koerfgen]

Hi Kevin,

On 08-Mar-00 Kevin D. Kissell wrote:
[...]
> 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.

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

> 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.

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

-- 
Regards,
Harald

Re: FP emulation patch available

[Kevin D. Kissell]

Hearald Koerfgen wrote:
>
>On 07-Mar-00 Andrew R. Baker wrote:
>> 
>> 
>> On Tue, 7 Mar 2000, Gleb O. Raiko wrote:
>>> "Bradley D. LaRonde" wrote:
>>> > 
>>> > I would jump right on this but I really need it for 2.3.47+.
>>> > 
>>> > Regards,
>>> > Brad
>>> 
>>> I vote for 2.3 too. It seems 2.2 will vanish soon anyway.
>> 
>> Working on it.
>
>Me too. Compiles and links but doesn't work. I guess the cpu detection doesn't
>work properly for my Mobilon yet. I am actually compiling it for a DECstation
>:-)


It's odd - I'm on at least one of the mailing lists in question, but I missed
part of this thread yesterday - such as Bradley's message, and another
that must have come from someone (Dom?) at Algorithmics.  

Anyway, the my CPU detection would certainly not have worked for
a Mobilon.   But it ought to have worked for a DECstation.  What
CPU does it have?   In addition to the cpu_probe() routine itself,
arch/mips/kernel/cpu_probe.c contains a table that describes the
CPU's that are recognized, and in principle it "knows" all the CPUs
that were recognized by the old assembler code in head.S, plus
a couple more (R4300 and MIPS 4Kc/5Kc).   The problem may
be a CPU that is mis-identified, or it may be that the options in the
table associated with that CPU are incorrectly defined.  Please
let me know what CPU and "PrID" the system has.

            Regards,

            Kevin K.

Re: FP emulation patch available

[Kevin D. Kissell]

Hearald Koerfgen wrote:
>
>On 07-Mar-00 Andrew R. Baker wrote:
>> 
>> 
>> On Tue, 7 Mar 2000, Gleb O. Raiko wrote:
>>> "Bradley D. LaRonde" wrote:
>>> > 
>>> > I would jump right on this but I really need it for 2.3.47+.
>>> > 
>>> > Regards,
>>> > Brad
>>> 
>>> I vote for 2.3 too. It seems 2.2 will vanish soon anyway.
>> 
>> Working on it.
>
>Me too. Compiles and links but doesn't work. I guess the cpu detection doesn't
>work properly for my Mobilon yet. I am actually compiling it for a DECstation
>:-)


It's odd - I'm on at least one of the mailing lists in question, but I missed
part of this thread yesterday - such as Bradley's message, and another
that must have come from someone (Dom?) at Algorithmics.  

Anyway, the my CPU detection would certainly not have worked for
a Mobilon.   But it ought to have worked for a DECstation.  What
CPU does it have?   In addition to the cpu_probe() routine itself,
arch/mips/kernel/cpu_probe.c contains a table that describes the
CPU's that are recognized, and in principle it "knows" all the CPUs
that were recognized by the old assembler code in head.S, plus
a couple more (R4300 and MIPS 4Kc/5Kc).   The problem may
be a CPU that is mis-identified, or it may be that the options in the
table associated with that CPU are incorrectly defined.  Please
let me know what CPU and "PrID" the system has.

            Regards,

            Kevin K.

Re: FP emulation patch available

[Richard van den Berg]

On Wed, 8 Mar 2000, Kevin D. Kissell wrote:

> It's odd - I'm on at least one of the mailing lists in question, but I missed
> part of this thread yesterday - such as Bradley's message, and another
> that must have come from someone (Dom?) at Algorithmics.  

Yep, you can read the thread that went through fnet.fr on the mailing list
archive, including Dom's message, at
http://web.inter.nl.net/users/schnecke/fnet-mips/2000-03/thread.html with
user mips and password rules.

Regards,
Richard

Re: FP emulation patch available

[Harald Koerfgen]

Hi Kevin,

On 08-Mar-00 Kevin D. Kissell wrote:
> Anyway, the my CPU detection would certainly not have worked for
> a Mobilon.   But it ought to have worked for a DECstation.  What
> CPU does it have?   In addition to the cpu_probe() routine itself,
> arch/mips/kernel/cpu_probe.c contains a table that describes the
> CPU's that are recognized, and in principle it "knows" all the CPUs
> that were recognized by the old assembler code in head.S, plus
> a couple more (R4300 and MIPS 4Kc/5Kc).   The problem may
> be a CPU that is mis-identified, or it may be that the options in the
> table associated with that CPU are incorrectly defined.  Please
> let me know what CPU and "PrID" the system has.

Been there, done that. It was just a missing case statement that got lost during
the merge :-)

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.

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?

-- 
Regards,
Harald

FP emulation patch available

[Andrew R. Baker]

I have made a patch against the 2.2.13 CVS kernel from the patch that
Kevin Kissell (sp?) put out earlier.  This patch is a subset of Kevin's
patch.  It includes the following pieces:

1) FPU emulation support
2) removal of the MIPS instruction bitfields (replaced with macros)
3) mips_cpu stucture and C based cpu identification

I think a gdb segment snuck in there too.

The patch is available at:
http://www.dpo.uab.edu/~andrewb/2.2.diff.2000.03.06

Could interested parties please look at it and provide more testing than
me and my Indigo2.  My next goal is to intergrate the FP unimplemented
exception code into the FPU emulation framework.  I then shall see about
moving it all to 2.3 (I may move parts sooner if necessary).  

Comments appreciated,

Andrew

P.S.  Ralf & others, since I keep changing desktop machines I do not
believe I have submit access to CVS anymore.  If this patch is
satisfactory, could one of you submit it to the archive for me?

Re: FP emulation patch available

[Andrew R. Baker]

On Tue, 7 Mar 2000, Gleb O. Raiko wrote:
> "Bradley D. LaRonde" wrote:
> > 
> > I would jump right on this but I really need it for 2.3.47+.
> > 
> > Regards,
> > Brad
> 
> I vote for 2.3 too. It seems 2.2 will vanish soon anyway.

Working on it.

-Andrew

Re: FP emulation patch available

[Harald Koerfgen]

On 07-Mar-00 Andrew R. Baker wrote:
> 
> 
> On Tue, 7 Mar 2000, Gleb O. Raiko wrote:
>> "Bradley D. LaRonde" wrote:
>> > 
>> > I would jump right on this but I really need it for 2.3.47+.
>> > 
>> > Regards,
>> > Brad
>> 
>> I vote for 2.3 too. It seems 2.2 will vanish soon anyway.
> 
> Working on it.

Me too. Compiles and links but doesn't work. I guess the cpu detection doesn't
work properly for my Mobilon yet. I am actually compiling it for a DECstation
:-)

-- 
Regards,
Harald

Re: FP emulation patch available

[Ralf Baechle]

On Tue, Mar 07, 2000 at 11:51:52AM +0300, Gleb O. Raiko wrote:

> > I would jump right on this but I really need it for 2.3.47+.
> > 
> > Regards,
> > Brad
> 
> I vote for 2.3 too. It seems 2.2 will vanish soon anyway.

Size, stability and existing drivers are arguments for 2.2 that will stay
valid for quite some time.

  Ralf

Re: FP emulation patch available

[Jay Carlson]

> Bradley D. LaRonde (brad@ltc.com) writes (re the FPA emulator out of
> Algorithmics via Kevin Kissell):
>
> > I would jump right on this but I really need it for 2.3.47+.
>
> It's good to see our donation to the Linux project being taken up
> enthusiastically , but didn't SGI have some code like this?  I mean,
> you can't have a serious MIPS run-time system without an FP emulator,
> can you?

quoting from softftp.S from 2.3.19:

 * For now it's just a crude hack good enough to run certain fp programs
like
 * Mozilla.

It's just dealing with denorms, NaNs, etc as inputs.  AFAIK NetBSD was no
better until pretty recently.

Whether Linux or NetBSD, as systems, were ever serious MIPS run-time
systems---well, you wrote the book, so I'm inclined to get out of the
argument.

>From my LinuxCE perspective, a full FP emu is fairly important for getting
binary compatibility back with mainline Linux/MIPS---we've been in the
softfp ghetto.  But most of what we do with FP is, uh, keep /bin/df happy
when it tries to calculate the percentage of free disk space, and the like.
And dropping softfp means we don't *have* to maintain a forked
toolchain/libc.

(of course, getting rid of softfp makes mips16 more...interesting...)

Jay

Re: FP emulation patch available

[Jay Carlson]

> Bradley D. LaRonde (brad@ltc.com) writes (re the FPA emulator out of
> Algorithmics via Kevin Kissell):
>
> > I would jump right on this but I really need it for 2.3.47+.
>
> It's good to see our donation to the Linux project being taken up
> enthusiastically , but didn't SGI have some code like this?  I mean,
> you can't have a serious MIPS run-time system without an FP emulator,
> can you?

quoting from softftp.S from 2.3.19:

 * For now it's just a crude hack good enough to run certain fp programs
like
 * Mozilla.

It's just dealing with denorms, NaNs, etc as inputs.  AFAIK NetBSD was no
better until pretty recently.

Whether Linux or NetBSD, as systems, were ever serious MIPS run-time
systems---well, you wrote the book, so I'm inclined to get out of the
argument.

From my LinuxCE perspective, a full FP emu is fairly important for getting
binary compatibility back with mainline Linux/MIPS---we've been in the
softfp ghetto.  But most of what we do with FP is, uh, keep /bin/df happy
when it tries to calculate the percentage of free disk space, and the like.
And dropping softfp means we don't *have* to maintain a forked
toolchain/libc.

(of course, getting rid of softfp makes mips16 more...interesting...)

Jay

Re: FP emulation patch available

[Ralf Baechle]

On Tue, Mar 07, 2000 at 07:08:23AM -0500, Jay Carlson wrote:

> Whether Linux or NetBSD, as systems, were ever serious MIPS run-time
> systems---well, you wrote the book, so I'm inclined to get out of the
> argument.
> 
> >From my LinuxCE perspective, a full FP emu is fairly important for getting
> binary compatibility back with mainline Linux/MIPS---we've been in the
> softfp ghetto.  But most of what we do with FP is, uh, keep /bin/df happy
> when it tries to calculate the percentage of free disk space, and the like.
> And dropping softfp means we don't *have* to maintain a forked
> toolchain/libc.

Have you considered contribution of the softfp code to GNU libc or
packaging it as a glibc addon?  For small embedded systems it seems to
be the better tradeoff than the kernel emulator and for these systems
nobody cares very much about binary compatibility with something else.

  Ralf

Re: FP emulation patch available

[Ralf Baechle]

On Tue, Mar 07, 2000 at 10:22:22AM +0000, Dominic Sweetman wrote:

> Bradley D. LaRonde (brad@ltc.com) writes (re the FPA emulator out of
> Algorithmics via Kevin Kissell):
> 
> > I would jump right on this but I really need it for 2.3.47+.
> 
> It's good to see our donation to the Linux project being taken up
> enthusiastically , but didn't SGI have some code like this?

They even have two emulators, an old one written in assembler and a newer
one written in C.  I haven't looked more closely but I think that they're
both full emulators and the (C) situation would allow me to reuse the
code for Linux.  In any case, it's a non-trivial piece of code, so I want
to double check with them.

> I mean, you can't have a serious MIPS run-time system without an FP
> emulator, can you?

Depends.  After a few years without this FPU stuff we've found only a
surprisingly small number of applications that run into problems.  After
all the only FPU instruction many programs execute is $fcr31.  Just
configuring all the kernel FPU code away therefore is a good thing
for many embedded configurations.

  Ralf