Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3EA6A58C.F2C08639@phekda.freeserve.co.uk>
Date:	Wed, 23 Apr 2003 15:39:08 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	DJGPP workers <djgpp-workers AT delorie DOT com>
Subject:	Re: 2.04 status page / 2.04 alpha 1 release schedule
References:	<10304231426 DOT AA12366 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Charles Sandmann wrote:
> 
> > 3) Charles sent out a potential fix for the uclock issue. See the
> > following URL:-
> >
> > http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2003/0
> > 3/09/22:02:19
> 
> I thought about this last night.  The code as posted isn't perfect, but
> probably could be checked in for wide spread testing - and works better
> than the current code.  We did discuss a hybrid approach which would be
> better (but more complex).  So if anyone has any strong opinions on
> commit yes/no for uclock() on win2k/XP, let me know.
[snip]

I think it can go in, as long as:

* The documentation mentions potential problems with processors that change
their clock speed (e.g.: mobile CPUs).

* The rdtsc call is protected, so it doesn't barf on processors that don't
have rdtsc.

If you commit it, please note that the fix is unfinished in the "What's
Changed" log, i.e.: more work required. That way we won't forget that we need
to look at it again, before releasing the next alpha/beta/final.

Basically: a slightly working uclock is better IMHO than a non-functional
uclock on Windows 2k/XP.

It would also be nice if you've fixed the following issues that you mentioned:

* Does it handle calibration over midnight?

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -