Subject: Floating point questions

From: "Andrew R. Baker" <[email-masked]>
Date: Mon, 17 Jan 2000 20:55:58 -0600 (CST)

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?  

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.  What would the drawbacks be of a save and
restore and the start and finish of the exception handler (well the
unimplemented handler)?  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.

-Andrew

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 18 Jan 2000 04:26:55 +0100

> where they are not in IRIX.  Is there a reason we do this?  Or is this

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.

> 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

This cannot happen.

  Ralf

---

From: "Andrew R. Baker" <[email-masked]>
Date: Mon, 17 Jan 2000 21:41:01 -0600 (CST)

> Btw, C9x provides interfaces to manipulate the exception bits.

OK, I'll just set my test progs to clear the enable bits.

> the context into the FPU and setting the CU1 bit.

I was basing my assumptions on what the sparc fpu system looked like.  The
code seems to infer that, in SMP, the fp emulator can be run for a process
that is not 'current'.  I'll stick with the direct access method than (I
like it better anyway).

I am going to try and add the rest of the ops this week and put something
out for people to look at.  Then I will clean it up some.  Is there any
disadvantage to leaving this as a module?

-Andrew

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 18 Jan 2000 04:53:34 +0100

> OK, I'll just set my test progs to clear the enable bits.

It may be hairy but I think you'll have to deal with exception sooner
or later ...

> disadvantage to leaving this as a module?

At least as in CVS the module doesn't make sense except for debugging -
we don't have a mechanism for loading it on demand.

  Ralf