On Sun, 29 May 2016, Don Lewis wrote:
Log:
Cast some expressions that multiply a long long constant by a
floating point constant to int64_t. This avoids the runtime
conversion of the the other operand in a set of comparisons from
int64_t to floating point and doing the comparisions in floating
point.
Suggested by: lidl
Submitted by: Rasool Al-Saadi <ralsa...@swin.edu.au>
MFC after: 2 weeks (with r300779)
Compilers are still permitted to (and perhaps even required to)
evaluate FP constant expressions at runtime (to get rounding and/or
exception flags right). They probably don't in practice, but it is
unclear what happens for -O0 and the rules for rounding are too hard
to understand.
Modified: head/sys/netpfil/ipfw/dn_aqm_pie.c
==============================================================================
--- head/sys/netpfil/ipfw/dn_aqm_pie.c Sun May 29 07:14:51 2016
(r300948)
+++ head/sys/netpfil/ipfw/dn_aqm_pie.c Sun May 29 07:23:56 2016
(r300949)
@@ -244,17 +244,17 @@ calculate_drop_prob(void *x)
p *= (PIE_MAX_PROB << 12) / AQM_TIME_1S;
/* auto-tune drop probability */
- if (prob< PIE_MAX_PROB * 0.000001)
+ if (prob < (int64_t)(PIE_MAX_PROB * 0.000001))
p >>= 11 + PIE_FIX_POINT_BITS+12;
+ else if (prob < (int64_t)(PIE_MAX_PROB * 0.00001))
p >>= 9 + PIE_FIX_POINT_BITS+12;
Why not just divide by integer powers of 10?
This might not give a suitably monotonic/continuous scaling at the
endpoints, but it is unclear if the FP gives that either even if we
are more careful with the rounding mode.
A table of endpoints could be used to get precise control. Then FP
can be used more safely, since it is clear that constants in tables
must be evaluated at compile time.
...
Similarly for all cases.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
