Mail Archives: djgpp-workers/2000/05/30/11:37:09
Eli Zaretskii wrote:
> First, I meant the long long version as well. And second, I was thinking
> about putting a fast inline version into stdlib.h as a macro, and making
> the function versions use that macro as their body. We do that for getc
> and putc, for example.
I took a look at this over the weekend. For div.c, inline assembly code was
no more efficient that the code I got from the C code I submitted earlier, so
it appears that nothing would really be gained by going to inline assembly.
The inefficiency was in excess data motion in the interface code that gcc put
in. Thus, the only way to improve the speed would be to make the entire
div() routine assembler. ldiv.c is really the same as div.c in the machine
code it should generate, so I didn't look at that routine. lldiv.c calls
subroutines to find the quotient and remainder, but that one can't be really
efficient anyway, since there is no i386 instruction that will handle a
64-bit divisor. (idivl will handle a 64-bit dividend, but the divisor is
limited to 32 bits, and the quotient had better not be longer than 32 bits,
either, or a divide exception occurs.)
The existing lldiv.c generates code that calls subroutines called ___moddi3
and ___divdi3, and I can't find the source for these routines. Does anyone
know where they are? I did a grep through the entire djlsr203 and didn't
find anything.
-Eric Rudd
rudd AT cyberoptics DOT com
- Raw text -