Philippe Gerum wrote:
 > 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.

Ok, we could then write:

static inline unsigned long long ns_2_cycles(unsigned ns)
{
    return (unsigned long long) ns * ns2cyc_scale >> NS2CYC_SCALE_FACTOR;
}

-- 


                                            Gilles Chanteperdrix.

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

Reply via email to