[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <aa5f1334222bb26e1da75694905b4314@kernel.crashing.org>
Date: Tue, 27 Feb 2007 04:45:00 +0100
From: Segher Boessenkool <segher@...nel.crashing.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Jan Engelhardt <jengelh@...ux01.gwdg.de>, netdev@...r.kernel.org,
Stephen Hemminger <shemminger@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] div64_64 support
> I thought the motivation for div64() was that a 64:32->32 divide could
> be done a lot faster on a number of platforms (including the important
> x86) than a generic 64:64->64 divide, but gcc doesn't handle the
> devolution automatically -- there is no such libgcc function.
That there's no such function in libgcc doesn't mean GCC
cannot handle this; libgcc is a bunch of library functions
that are really needed for generated code (because you
really don't want to expand those functions inline
everywhere) -- you won't find an addsi3 in libgcc either.
There does exist a divmoddisi4, sort of.
It used to be defined in three GCC targets, but commented
out in all three. The NS32k is long gone. For Vax, a
comment says the machine insn for this isn't used because
it is just too slow. And the i386 version is disabled
because it returns the wrong result on overflow (not the
truncated 64-bit result, required by the implicit cast
to 32-bit, but the i386 arch traps to the overflow handler).
The only way to express the semantics you want in (GNU) C
is to use asm() -- and that's exactly what div64() does :-)
Blame it on the C language, but not on GCC. Not this time.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists