It really blew my mind when "Letz Stephane" <[EMAIL PROTECTED]> said:
> I made some tests on a G3 with Code Warrior 5 with optimizations on (Mac OS
> 8.6). The lrint/lrintf is slower that the standard cast code.
Hmm, thats very interesting. Maybe we can take this off line and work on
a solution. Interested?
> Here are the result of disassembing 2 tests functions :
>
>
> int test1 (float in){ return lrintf(in); } gives :
>
> ...
> 00000000: 7C0802A6 mflr r0
> 00000004: 90010008 stw r0,8(SP)
> 00000008: 9421FFC0 stwu SP,-64(SP)
> 0000000C: 48000001 bl .rinttol
> 00000010: 60000000 nop
> 00000014: 80010048 lwz r0,72(SP)
> 00000018: 38210040 addi SP,SP,64
> 0000001C: 7C0803A6 mtlr r0
> 00000020: 4E800020 blr
> ...
>
> Is seems that lrint/lrintf are implemented in the MathLib using the rinttol
> call.
On linux, this is an inline function while on Mac its a function call. Maybe we can
do better. I am far from beting a PPC assembler expert (in fact I've never looked
at it) but I understand that PPC has at least two float to int conversion functions;
one for truncation and one for rounding. Is that correct?
If this is the case, then maybe we can use and inline function with assembler in
it.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid)
+-----------------------------------------------------------+
"It is grossly irresponsible to connect a Windows machine directly to
the net. ;-)" -- John Wiltshire on the Sydney Linux User Group mailing list
