linux-mips
[Top] [All Lists]

Re: Floating point questions

To: "Andrew R. Baker" <andrewb@uab.edu>
Subject: Re: Floating point questions
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Tue, 18 Jan 2000 04:26:55 +0100
Cc: Linux SGI <linux@cthulhu.engr.sgi.com>, Ralf Baechle <ralf@oss.sgi.com>
In-reply-to: <Pine.LNX.3.96.1000117204924.28191E-100000@mdk187.tucc.uab.edu>
References: <Pine.LNX.3.96.1000117204924.28191E-100000@mdk187.tucc.uab.edu>
Sender: owner-linuxmips@oss.sgi.com
On Mon, Jan 17, 2000 at 08:55:58PM -0600, Andrew R. Baker wrote:

> Whilst playing with floating point support I have noticed that the
> "Division By Zero" and "Overflow" Enable bits are set by default on Linux
> where they are not in IRIX.  Is there a reason we do this?  Or is this
> behaviour unintended?  

We've got two versions of libc circulating.  The one enables a number
of exceptions, same as an old libc 4 or 5 from ~95.  The current and
correct one just leaves all exceptions disabled.

Btw, C9x provides interfaces to manipulate the exception bits.

> Also, when we enter the floating point handler, the floating point
> registers have not been saved to the thread structure.  Currently, I get
> around this by querying the registers directly.  Unfortunately this won't
> work when we support SMP.

Why should this not be working with SMP?  Only when the FPU contains the
current' processes' fp context CP1 is enabled in the status register.
If not any attempt to execute the fp instruction will result in a
Coprocessor Unavailable exception which will be serviced by loading
the context into the FPU and setting the CU1 bit.

> What would the drawbacks be of a save and restore and the start and
> finish of the exception handler (well the unimplemented handler)?

Performance.

>  Or is there some other way?  I'm really only
> concerned about the case where we would run the soft-fp code on a
> processor other than the one that triggered the exception.

This cannot happen.

  Ralf

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