From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10302131539.AA14055@clio.rice.edu>
Subject: Re: _rdtsc proposal
To: djgpp-workers AT delorie DOT com
Date: Thu, 13 Feb 2003 09:39:33 -0600 (CST)
In-Reply-To: <3E4B442E.6B87CC24@yahoo.com> from "CBFalconer" at Feb 13, 2003 02:07:26 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> What I worry about is that the instruction will slip into
> something critical or other, and just lie there until someone with
> a 486 (like me) tries to use it.  It should be hard to access it,
> and the access should only be via a routine that can protect it. 
> So timer resolution falls - tough.

The specific _rdtsc I proposed is good for pentium profiling,
since there is very little overhead.  Putting it into a protected
routine would hurt it's effectiveness.  I think this is a 
documentation issue that it shouldn't be used in "unprotected"
code.  uclock() will be the protected code.

I try to test these types of patches on a 386 (with no 387) laptop
that I have saved just for testing.  Someday I'll set up an emulator
for testing - but until the hardware breaks I'll continue to use it.

By the way, does anyone have a real 386 with less than 1Mb of 
physical memory still working?  I think I broke raw memory support
for this configuration some time back in CWSDPMI.  But it seems no
one has noticed ...  In particular, we test for A20 enabled even if
there is no memory there to test.