lkml.org 
[lkml]   [2000]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 64 bit divide/mod in 2.4.0-test5
Date
In article <8mflv4$lit$1@cesium.transmeta.com>,
H. Peter Anvin <hpa@zytor.com> wrote:
>
>There is also big difference on some architectures between 64/32 = 64
>and 64/32 = 32 (the latter is a single, albeit slow, instruction on
>x86.) I'm rather surprised gcc doesn't handle this -- it seems as an
>obvious optimization.
>
>Could we get the gcc people to look at this?

Probably not.

Doing 64/32->32 thing as a single instruction on x86 is an illegal
optimization: if your source code looks like

unsigned long a, b;
unsigned long long c;

a = c / b;

then according to the C language the c/b division is actually a
64/promoted64 bit division, and then the 64-bit result casted down to 32
bits.

What's the difference? Overflow. The cast from 64 bits to 32 bits cannot
overflow, so gcc would have to basically always do the 64/32->64 bit
division, and then just silently drop the extra bits in order to get the
right end result.

Now, that 64/32->64 bit division is fairly simple on x86 (certainly
simpler than the 64/64->64 one), and that's actually what do_div() will
use on x86. But it's two "div" instructions, not one (the first one can
often be optimized away if the upper 32 bits are usually 0, which is the
case 99%+ of the time with most regular distributions of numbers).

Note that the 64/32->64 division is a _lot_ simpler than the 64/64->64
one, so this is definitely still worth doing. But it's not a single
instruction.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.074 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site