Paul Sidorsky wrote in a message to Murray Lesser:

 ML> technique is described in Michael Abrash's (unfortunately) out-of-print
 ML> book: "Zen of Assembly Language" under the heading
"The Zen Timer."

 PS> D'OH!  I'm still trying to find that book second hand, as
 PS> it's been highly recommended to me by others.  I guess I
 PS> have one more reason to look for it now. 

Available here for FReq or download:

ZENDISK1.ZIP   57K  2-14-90  Listings from 'Zen of Assembly Language', #1
ZENDISK2.ZIP   96K  2-14-90  Listings from 'Zen of Assembly Language', #2

Abrash has a couple of successor books in print, "Zen of Code
Optimization" is noteworthy.  I am surprised to hear that "Zen of
Assembly Language" is O.P., since it is without question the finest
book on 80x86 assembly language ever written.  I know that it sold badly,
probably under 10,000 copies, but is the definitive classic in its field.

Anyone looking for second-hand technical books should start with Books From
Bree, 6716 Clybourn Avenue, Unit 153, North Hollywood, CA  91606; e-mail to
.

I was quite surprised to see that Abrash headed the graphics team for a
while on the Windows NT project.  His involvement is probably the only
reason the code works at all.  :)

 ML> Abrash claims "relative timings" good to 10 microseconds (0.000010
 ML> second) when the technique is used with care.

 PS>   Nice.  I only need millisecond accuracy myself
 PS> (and that's in DOS, not OS/2), but it's nice to know I can
 PS> get more.

Abrash is interested in relative timing in order to compare the speed of
approaches when actually implemented in real code.  If you need millisecond
accuracy in absolute terms, his techniques may not be what you want.

 ML>     As I understand it, there are similar ways to measure very small
 ML> time intervals under OS/2, since the hardware hasn't changed, but these
 ML> require delving into device drivers--something I know nearly nothing
 ML> about.  There is a profiler that comes with CSet++ (EXTRA) that requires
 ML> having loaded its device driver before it can be used.  Perhaps one of
 ML> the DD gurus in this conference might wish to stick an oar in.

 PS> Argh, I sure hope not.  Device drivers give me the heebie
 PS> jeebies, as I'm sure they do a lot of people.

Well, I do a lot of OS/2 device driver work, and you would be far better
off trying to deal with timing from inside a device driver.  There are
actually a lot of undocumented techniques that can be used inside OS/2,
even from application level, to get very accurate timings, but you need to
buy something like System Performance Monitor for OS/2 (SPM/2).

Note also that CPUs may have undocumented features that allow careful
performance measurement with little uncertainty.  For example, the Pentium
has an undocumented register that functions as a 64-bit absolute clock.  An
explanation of some of these features is available in the excellent book
"The Undocumented PC" by Frank van Gilluwe.

 PS> One related question - how accurate are the delay/wait times
 PS> passed to the OS/2 API functions, such as DosSleep() and the
 PS> DosWait...Sem() functions?  If they're accurate to the
 PS> millisecond, then there logically should be some way to time
 PS> to at least the millisecond level without a device driver.

These API calls measure CPU time, not absolute time.  Although there are
API calls which use absolute time, such as DosTimerStart(), no documented
API call provides resolution better than the system scheduler, 31 ms.
 
-- Mike


---