This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: clock() problem?
Hugo Tyson wrote:
>
> Chris Houston <chouston@logikos.com> writes:
> > Has anyone else encountered strange behaviour when using the "clock()"
> > function? When I use it, the result seems to roll over int 16 bits.
> >
> > In packages/language/c/libc/time/v1_x_x/src/clock.cxx, in the clock()
> > function, if I change
> >
> > clocks = ((clock_t)curr_clock * resolution.dividend) /
> > (resolution.divisor * (1000000000 / CLOCKS_PER_SEC));
> >
> > to
> >
> > clocks = (clock_t)((curr_clock * resolution.dividend) /
> > (resolution.divisor * (1000000000 / CLOCKS_PER_SEC)));
> >
> > then the function seems to behave correctly. It seems that in
> > the first case, the multiplication in the numerator gets truncated to
> > 32 bits.
>
> Overflow bites, I guess. Or maybe a more liberal sprinkling of casts is
> needed to make all the maths be 64 bit.
This happened inadvertently a while back due to clock_t being changed to be
more Linux compatible, but it's now fixed (and in anoncvs).
> This really needs rewriting to use the C++ clock conversion facility in the
> kernel;
Too much overhead for something straightforward IMHO.
> look for the word "converter" in clock.hxx and also see the
> clockcnv.cxx kernel testcase. Clock converters split
>
> foo = bar * A / (B * (10^9/CLOCKS_PER_SEC))
>
> into
>
> foo = bar * P / Q * R / (S * (10^9/CLOCKS_PER_SEC))
>
> where PR==A and QS==B so as to retain accuracy whilst avoiding overflow.
Which is now what clock() does. I think. Depending on what you thing PQRS
are :-).
Jifl
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault