Hello Mike!

In a message written on Friday May 26 1995, Mike Bilow insanely
babbles to Paul Sidorsky:

 MB> Available here for FReq or download:

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

Great.  Now if I could only fully read assembler.  :-)

 MB> Abrash has a couple of successor books in print, "Zen of Code
 MB> Optimization" is noteworthy.

I got a clip from this book in PowerPC News, it looks nice.

 MB> I am surprised to hear that "Zen of Assembly Language" is
O.P., since
 MB> it is without question the finest book on 80x86 assembly language
 MB> ever written.  I know that it sold badly, probably under 10,000
 MB> copies, but is the definitive classic in its field.

True.  It's been highly recommended to be my a number of people.

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

I'll jot this down.  I hope they take Canadian orders.  :-)

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

  Now he's working for id on their QUAKE project.  _That_ will
be interesting to see.

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

As long as I can break out of a loop after approximately so many
milliseconds, I'll be happy.  I know I could fake this by just using
clock() calls (especially in BC-OS/2 where it's define as 1000) but I want
better accuracy than that.  I have a timer routine (for DOS) from SWAGS,
the Pascal snippets collection, so I just need to convert that over to C. 
Would be nice to know how to design my own though, especially if I need one
for OS/2, since I'm not sure the same technique will work.

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

Hmmm... well, if learning device driver work will help me out, then,
damnit, that's what I'll do.  But not right now.  :-)

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

Argh!  No more books!  I need a loan for all these books already!  :-)

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

Ahh.  Man, this is a disilliusioning conversation.  I always thought
accurate timing would be easy for CPUs this fast.  

 -- PaulS

--- FMail/386 1.0g