Date: Sun, 12 Mar 2000 12:50:18 +0000 From: Paul Richards <paul@originative.co.uk> To: Doug Rabson <dfr@nlsystems.com> Cc: Jeroen Ruigrok van der Werven <asmodai@bart.nl>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Alfred Perlstein <bright@wintelcom.net>, Martin Cracauer <cracauer@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include npx.h Message-ID: <38CB928A.E4B691B1@originative.co.uk> References: <Pine.BSF.4.21.0003110840550.79394-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > > On Fri, 10 Mar 2000, Jeroen Ruigrok van der Werven wrote: > > > -On [20000310 22:30], Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: > > ><<On Fri, 10 Mar 2000 13:39:36 -0800, Alfred Perlstein <bright@wintelcom.net> said: > > > > > >> Is there any reason for doing this other than so we can emulate > > >> linux's bog^H^H^H nifty ability to divide by zero? > > > > > >The fact that the IEEE standard says this is the default state. > > > > My, does the IEEE encourage bad coding practices then. If I understood > > the commit correctly. > > > > Just for the less kernelsavvy types under us, > > > > this commit make sures that my app won't segfault due to a division by > > zero, right? > > This means that you won't get a SIGFPE for floating point overflow > (including divide by zero) among other things. > > This is useful for certain kinds of floating point software, including 3D > graphics, where the cost of detecting whether an operation will overflow > is prohibitive. Also neural network modelling. In the early days of FreeBSD, when I was doing my Phd, it used to be a real pain when after two days of running a simulation the program just went and died! None of the other OSs did this. In NN modelling it's "normal" for the numbers to get out of range and the software correctly checks for these conditions but the software never got a chance before. Now things will work as expected. A very good change IMO. The previous settings were only a safety net for poor code that didn't check conversion results. Paul. p.s. Yes I know a signal handler would have stopped this, but it was actually much simpler to change the mask since the simulators were generally written to work correctly on Solaris where instead of a trap you'd get a value such as NaN which the software could interpret appropriately. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38CB928A.E4B691B1>