Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
 > static inline unsigned long long ns_2_cycles(unsigned long long ns)
 > {
 >      return ns * ns2cyc_scale >> NS2CYC_SCALE_FACTOR;

This multiplication is 64 bits * 32 bits, the intermediate result may
need more than 64 bits, so you should compute it the same way as the
beginning of ullimd. Something like:

Sure, but the point is that if we were to use such code, we should bound the 64bit operand and would not use it beyond the tolerable loss of accuracy on output (e.g. 2ms). This would require to break longer shots in several smaller ones, relying on the internal timer management logic to redo the shot until it has actually elapsed (which should be a rare case for oneshot timing), a bit like we are currently doing in bounding the values to 2^32-1 right now. Going for ullimd alike implementation somehow impedes the overall effort in reducing the CPU footprint, I guess. This said, I have still no clue if the gain in computation cycles is worth the additional overhead of dealing with possibly early shots - I tend to think it would be better on average though.


static inline unsigned long long ns_2_cycles(unsigned long long ns)
{
    unsigned nsh, nsl, tlh, tll;
    unsigned long long th, tl;

    __rthal_u64tou32(ns, nsh, nsl);
    tl = rthal_ullmul(nsl, ns2cyc_scale);
    __rthal_u64tou32(tl, tlh, tll);
    th = rthal_ullmul(nsh, ns2cyc_scale);
    th += tlh;

    tll = (unsigned) th << (32 - NS2CYC_SCALE_FACTOR) | tll >> 
NS2CYC_SCALE_FACTOR;
    th >>= NS2CYC_SCALE_FACTOR;
    return __rthal_u64fromu32(th, tll);
}




--

Philippe.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to