[Top] [All Lists]

Re: Floating point questions

To: Ralf Baechle <>
Subject: Re: Floating point questions
From: "Andrew R. Baker" <>
Date: Mon, 17 Jan 2000 21:41:01 -0600 (CST)
Cc: Linux SGI <>
In-reply-to: <>

On Tue, 18 Jan 2000, Ralf Baechle wrote:
> 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.

OK, I'll just set my test progs to clear the enable 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.

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?


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