From: | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
Newsgroups: | comp.compilers |
Date: | 15 May 2005 15:42:52 -0400 |
Organization: | Institut fuer Computersprachen, Technische Universitaet Wien |
References: | 05-05-063 05-05-082 |
Keywords: | arithmetic, performance |
Posted-Date: | 15 May 2005 15:42:52 EDT |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>"Jonathan Epstein" <Jonathan_Epstein@nih.gov> writes:
>>What if I were willing to settle for a 96-bit dividend and a 64-bit
>>divisor?
>
>That would really fly on the x64-64 architecture, which has a native
>128-by-64-bit division (PPC64 only has 64-by-64-bit).
One thing I forgot is that there is no way to get at that feature (or
the 386's 64-by-32-bit division) without at least a little assembler
involvement, which looks like this in GNU C:
asm("divq %3": "=a"(n3),"=d"(n2) : "A"(d1),"g"(n1):"cc");
for unsigned division of d1 by n1 resulting in modulus n2 and quotient
n3.
The reason that gcc does not do such things automatically when you
divide the appropriate types is the fact that the CPU gives exceptions
for overflows in some cases where the C way of doing things (expand
the divisor to 128 bits, divide 128-by-128-bit, then convert the
result back to 64 bits) does not produce an exception in gcc-generated
code.
- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html
Return to the
comp.compilers page.
Search the
comp.compilers archives again.