From owner-cvs-all Sun Mar 12 4:52: 5 2000 Delivered-To: cvs-all@freebsd.org Received: from mail.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 7F63937BBCE; Sun, 12 Mar 2000 04:50:26 -0800 (PST) (envelope-from paul@originative.co.uk) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mail.originative.co.uk (Postfix) with ESMTP id 68C0D1D132; Sun, 12 Mar 2000 12:50:17 +0000 (GMT) Message-ID: <38CB928A.E4B691B1@originative.co.uk> Date: Sun, 12 Mar 2000 12:50:18 +0000 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en-GB, en MIME-Version: 1.0 To: Doug Rabson Cc: Jeroen Ruigrok van der Werven , Garrett Wollman , Alfred Perlstein , Martin Cracauer , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include npx.h References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: > > >< 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