Date: Tue, 30 May 2000 10:35:31 -0500 From: Eric Rudd Subject: Re: Bug 314 To: djgpp-workers AT delorie DOT com Message-id: <3933DFC3.D8C10F5C@cyberoptics.com> Organization: CyberOptics MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Reply-To: djgpp-workers AT delorie DOT com 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