From owner-freebsd-multimedia Thu May 13 5: 2:25 1999 Delivered-To: freebsd-multimedia@freebsd.org Received: from grisu.bik-gmbh.de (grisu.bik-gmbh.de [194.233.237.82]) by hub.freebsd.org (Postfix) with ESMTP id 4F84C14DDB; Thu, 13 May 1999 05:02:20 -0700 (PDT) (envelope-from cracauer@counter.bik-gmbh.de) Received: from counter.bik-gmbh.de (counter.bik-gmbh.de [194.233.237.131]) by grisu.bik-gmbh.de (8.8.8/8.6.9) with ESMTP id OAA02988; Thu, 13 May 1999 14:02:17 +0200 (MEST) Received: (from cracauer@localhost) by counter.bik-gmbh.de (8.9.3/8.8.8) id NAA43679; Thu, 13 May 1999 13:58:20 +0200 (CEST) (envelope-from cracauer) Date: Thu, 13 May 1999 13:58:20 +0200 From: Martin Cracauer To: Doug Rabson Cc: Brian Feldman , eagle , John-Mark Gurney , Lee Cremeans , hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: G200 GLX and SIGFPU Message-ID: <19990513135820.A43622@cons.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Doug Rabson on Sat, May 08, 1999 at 10:21:34PM +0200 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In , Doug Rabson wrote: >It looks like __BETTER_BDE_NPXCW__ would mask OVF, DIV0 and INV which I >think is a better default. Is there some reason other than inertia for not >changing to __BETTER_BDE_NPXCW__? The "official" reason that FreeBSD still defaults to unmasked FPEs is that the Intel architekture doesn't allow you to handle "normal" computation errors (over/undeflow, div by zero etc.) differently from "real errors" in the FPU, like a FPU stack over/underflow and completely invalid operations. If you use __BETTER_BDE_NPXCW__, you will get rid of the FPEs in bad computations and at the same time disable the ability to catch "serious" FPU errors, which may be caused by bad compilers or inline assembly (not that uncommon in scientify floating point code or X servers). In a word, if you are on Intel processor's, it's always better to make your computations in a way that you test for exceptional values that would cause FPEs prior to the computation and leave FPEs enabled. The alternative is to install a handler for SIGFPE and let that one decide whether the exception was harmless or not. This is possible using the FPE trapcode patch I sent to -current a while ago. A version for last weeks 4.0-current is available by mail. Should run on 3.x as well. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.bik-gmbh.de/~cracauer/ "Where do you want to do today?" Hard to tell running your calendar program on a junk operating system, eh? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message