Date: Sun, 9 May 2004 23:45:32 -0700 From: David Schultz <das@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Fixing ilogb() Message-ID: <20040510064532.GB23610@VARK.homeunix.com> In-Reply-To: <20040510155514.L1063@gamplex.bde.org> References: <20040508194748.GN29712@wombat.fafoe.narf.at> <20040508225838.GA15663@VARK.homeunix.com> <20040509201148.P8241@gamplex.bde.org> <20040510155514.L1063@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 10, 2004, Bruce Evans wrote: > On Sun, 9 May 2004, I wrote: > > > ... > > % @@ -43,11 +43,27 @@ > > % subl $4,%esp > > % > > % fldl 8(%ebp) > > % + fxam > > % + fnstsw %ax > > % + sahf > > > > This is the main runtime overhead. I think it can mostly be avoided by > > checking the return value. ilogb() can only be INT_MIN after overflow > > or other conversion errors (check this). There 3 cases: > > - logb(0) = -Inf; fistpl(-Inf) = INT_MIN + IE > > - logb(Inf) = Inf; fistpl(-Inf) = INT_MIN + IE > > - logb(NaN) = same NaN; fistpl(NaN) = INT_MIN + IE > > After finding one of these rare cases, the exact case still needs to be > > determined by looking at the original value or the result of fxtract. > > Then fucom with 0 should be a faster way to do the classification. A > > full classification is not needed sice denormals are not special here > > and unsupported formats are unsupported here too. > > Another thing to decide is whether the exception flags should be set (or > not) to indicate overflow. I think they should be. Checking after doing > the operation sets them; checking before does not. The standard is not > clear. It says that the result is equivalent to (int)logb() for the > non-overflowing cases but has special rules with unusual wording for > the overflowing cases. It says "If x is zero they [the ilogb functions] > compute the value FP_ILOGB0. ..." Computation a constant value is > different from returning it, so this can be interpreted as saying that > the exception flags may be set. I think there's a meta-rule that math > functions set execption flags where appropriate. ilogb() isn't part of IEEE-754 and it is poorly specified in C99, but it is a proposed addition to the next revision of 754, namely IEEE-754R. In that proposal, ilogb() signals no exceptions, except for the automatic invalid exception you get from a signalling NaN. See http://754r.ucbtest.org. (This seems strange, given that logb(0) signals a divide-by-zero exception, but the proposal is quite specific.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040510064532.GB23610>