lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lightning] About jit_roundr_d_i


From: Paulo César Pereira de Andrade
Subject: [Lightning] About jit_roundr_d_i
Date: Thu, 9 Sep 2010 19:21:15 -0300

  Hi,

  [In i386, using ix87 coprocessor]

  The default implementation, assuming following the
"round" definition and default (round to nearest) rounding mode,
is actually wrong because of ties. The problem is that on
ties, "round" should round away from zero, but there is
no such rounding mode, only the default, towards zero.

  So, the current jit_roundr_d_i should be renamed to
something like jit_rintr_d_i, or (to add more confusion :-)
renamed to jit_extr_d_i, and a proper jit_roundr_d_i
implemented.

  BTW, is this really correct?
extr_d_f  o1 o2    <- convert float o2 to double o1
extr_i_d  o1 o2    <- convert int o2 to double o1

If extr_i_d means "int to double", then extr_d_f
should mean "double to float", and not "float to double"
(maybe I got it right the first time, when I made the
patch for SSE where there is a distinction of floats
and doubles :-)

  I am now working on the ix87 code, in my "work"
branch. Another issue I am having is about the
current logic for the float/double to integer conversions.
I am learning a bit more how things work, and about
the current implementation. The major change I
did so far was to add initial macros for int64, when
enabling x87 in x86_64, and added code to use
FISTTP instead of the more complex logic for
jit_truncr_d_i, i.e., now it is just:

__jit_inline void
jit_truncr_d_i(jit_gpr_t r0, int f0)
{
    PUSHLr(_RAX);
    FLDr(f0);
    FISTTPLm(0, _RSP, 0, 0);
    POPLr(r0);
}

(there is only FISTTP, no FISTT, so, need to
load the value, and pop it, instead of using
FXCH, but it should still be cheap as it does,
correctly, rounding towards zero on ties)

  But another thing is that I plan to make some
experiments with FLDCW (saving on a stack
slot) and FSTCW or FNSTCW and use rounding
modes, as a possible alternate to the current logic
in the jit_calc_diff() macro; whatever is faster, as
long as working correctly, wins :-) But the main
issue is the problem with jit_roundr, as it is
desirable to have a very fast double->int, and it
is "rint", that uses the default fpu mode, that is
to round ties toward zero...

Paulo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]