delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/04/29/16:57:10

Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EAEE6FE.5603E13F@phekda.freeserve.co.uk>
Date: Tue, 29 Apr 2003 21:56:30 +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 AT delorie DOT com
Subject: Re: uclock proposed patch
References: <10304291606 DOT AA20558 AT clio DOT rice DOT edu>
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Charles Sandmann wrote:
[snip]
> > I don't like the idea of installing the signal handler, if we don't need
> > it. I suppose this would have the disadvantage that the code will behave
> > differently on systems with and without RDTSC. That may be a problem, if
> > no-one tests it on a system without RDTSC. I certainly don't have any
> > systems without RDTSC. So maybe it would be best to always install it.
> 
> I decided it would be best to temporarily install it, see if it works,
> and if so remove the handler and use it.  If not, then don't call rdtsc.
> But if rdtsc isn't available, I can either just make the high precision
> bits all zero, or skip to the PIT code.  (Which is better, flakey
> high precision, or no high precision?  Currently we do flakey ...)

If you want high precision, I guess you also want it to be non-flakey. My
feeling is that no high precision would be better than flakey high precision.
Perhaps we could add YADO (Yet Another Documented Option) to let the user
choose?

[snip]
> Of course (and wc204..).  But I'd rather write the code 3 times and
> docs once, instead of each 3 times :-)

Sure. I thought you might have missed it out of the diff, though.

> > If so, maybe we should mention the fact we add a handler for SIGILL.
> > A user program will need to chain SIGILL, if
> > they install a SIGILL handler after calling uclock.
> 
> I'll document it installs a temporary handler and restores it.  But then
> the user shouldn't be concerned unless they have installed a handler
> and done something they expect the library code to generate some
> additional unexpected SIGILL in about 10 lines of code...
> 
> > Where is th the _rdtsc function/macro defined?
> 
> it's in time.h - it's either a inline function or a real function
> when compiled without optimization.  I added it several months ago;
> it's quite useful for other things too.  The texinfo docs for _rdtsc
> contain the same code fragment as an example for protecting it's usage.

Oh, sorry, I missed that. Thanks.

Thanks for explaining the other stuff too.

Bye, Rich =]

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019