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 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 Subject: Re: 2.04 status page / 2.04 alpha 1 release schedule References: <10304231426 DOT AA12366 AT clio DOT rice DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/ ]