On Tue, 27 Feb 2007 00:02:50 +0100 (MET)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Feb 26 2007 13:28, Stephen Hemminger wrote:
> >>
> >> ./arch/arm26/lib/udivdi3.c
> >> ./arch/sh/lib/udivdi3.c
> >> ./arch/sparc/lib/udivdi3.S
> >>
> >> should not this be consolidated too?
> >
> >Hmm. Those are the GCC internal versions, that are picked up but
> >doing divide in place. Do we want to allow general 64 bit in kernel to
> >be easily used? It could cause sloppy slow code, but it would look
> >cleaner.
>
> Then our reviewers should catch it, and if not, the janitors will
> (/me winks at R.P.J.Day and trivial@).
>
> >@@ -134,7 +112,7 @@
> > */
> > do {
> > x1 = x;
> >- x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3;
> >+ x = (2 * x + (u32) (a / x*x)) / 3;
>
> Eye see a bug.
>
> Previously there was div64_64(a, x*x) which is equivalent to
> (a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is
> equivalent to a*x/x (in the domain of real numbers). Furthermore,
> a/x*x is a-(a%x), which does not even remotely match a/(x^2).
>
> Please keep the math intact, thank you ;-)
Been there, done that, don't want to repeat it...
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
