[uClibc]Re: CLK_TCK fair well messed up

[Manuel Novoa III]

Miles,

Sorry I didn't get the CLK_TCK issue fixed today.  I should have time
tomorrow though.

On Thu, Jul 11, 2002 at 10:19:57AM +0900, Miles Bader wrote:
> mjn3 at codepoet.org (Manuel Novoa III) writes:
> > In an effort to minimize codesize, I implemented clock() to deal with the
> > currently possible values of CLK_TCK and left an #error test in to flag a
> > problem if the situation changes.  In fact, I think it is better to leave
> > the #error test in place for unsupported values, rather than attempt to do 
> > a canned solution that might introduce more integer arithemtic error
> > than necessary.
> 
> In what cases is the code gcc produces for the `simple' calculation
> (ticks * (CLOCKS_PER_SEC / CLK_TCK)) unreasonable?  [sorry, I'd like to
> check the existing special case code so that I can ask a more informed
> question, but the fileserver where my uclibc source is stored is
> currently down!]

What about when CLOCKS_PER_SEC isn't a multiple of CLK_TCK?  Since we are
using integer arithmetic, ticks * (CLOCKS_PER_SEC / CLK_TCK) isn't
always equal to (ticks * CLOCKS_PER_SEC) / CLK_TCK, even assuming no
overflow.  That's why we need the more involved expression when CLK_TCK
is 1024.

Also, I'm not just coding for gcc.  If you look at most of the code I've
written for uClibc, you'll see preprocessor tests involving __BCC__ on
occasion.  You'll also see a lot of "register" use.  That's because I'm
also intending to use much of my lib code with elks and the bcc compiler
is rather poor at optimizing.

> It seems kind of silly to require that all possible CLK_TCK values be
> explicitly listed in the code.

As far as I know, right now the only possiblities on linux are 100 and
1024.  I threw in a few extra while I was at it, but it isn't exactly
an exhaustive list.  I doubt that there will ever be that many
different values to deal with.  I put the #error message there to flag
when they occur.

Manuel