Gilles Chanteperdrix wrote:
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;
}


Yep.

--

Philippe.

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

Reply via email to