Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

30
03-05.md
View file

@ -19,10 +19,10 @@ transparent to the calling code.
If you do change the Zen timer routines to far procedures in order to
call them from code running in another segment, be sure to make *all*
the Zen timer routines far, including **ReferenceZTimerOn** and
**ReferenceZTimerOff**. (You’ll have to put **FAR PTR** overrides on the
**ReferenceZTimerOff**. (You'll have to put **FAR PTR** overrides on the
calls from **ZTimerOff** to the latter two routines if you do make them
far.) If the reference routines aren’t the same type—near or far—as the
other routines, they won’t reflect the true overhead incurred by
far.) If the reference routines aren't the same type—near or far—as the
other routines, they won't reflect the true overhead incurred by
starting and stopping the Zen timer.
Please be aware that the inaccuracy that the Zen timer can introduce
@ -34,16 +34,16 @@ dynamic RAM refresh, and internal timing variations in the 8253 make it
perhaps more accurate to describe the Zen timer as measuring code
performance with an accuracy of better than 10µs. In fact, the Zen timer
is actually most accurate in assessing code performance when timing
intervals longer than about 100 µs. At any rate, we’re most interested
intervals longer than about 100 µs. At any rate, we're most interested
in using the Zen timer to assess the relative performance of various
code sequences—that is, using it to compare and tweak code—and the timer
is more than accurate enough for that purpose.
The Zen timer works on all PC-compatible computers I’ve tested it on,
The Zen timer works on all PC-compatible computers I've tested it on,
including XTs, ATs, PS/2 computers, and 386, 486, and Pentium-based
machines. Of course, I haven’t been able to test it on *all*
PC-compatibles, but I don’t expect any problems; computers on which the
Zen timer doesn’t run can’t truly be called “PC-compatible.”
machines. Of course, I haven't been able to test it on *all*
PC-compatibles, but I don't expect any problems; computers on which the
Zen timer doesn't run can't truly be called "PC-compatible."
On the other hand, there is certainly no guarantee that code performance
as measured by the Zen timer will be the same on compatible computers as
@ -53,7 +53,7 @@ the opposite is true. For example, every PS/2 computer, even the
relatively slow Model 30, executes code much faster than does a PC or
XT. As another example, I set out to do the timings for my earlier book
*Zen of Assembly Language* on an XTcomputer, only to find that the
computer wasn’t quite IBM-compatible regarding code performance. The
computer wasn't quite IBM-compatible regarding code performance. The
differences were minor, mind you, but my experience illustrates the risk
of assuming that a specific make of computer will perform in a certain
way without actually checking.
@ -66,7 +66,7 @@ computers.
### A Sample Use of the Zen Timer {#Heading11}
Listing 3.2 shows a test-bed program for measuring code performance with
the Zen timer. This program sets DS equal to CS (for reasons we’ll
the Zen timer. This program sets DS equal to CS (for reasons we'll
discuss shortly), includes the code to be measured from the file
TESTCODE, and calls **ZTimerReport** to display the timing results.
Consequently, the code being measured should be in the file TESTCODE,
@ -84,11 +84,11 @@ and should contain calls to **ZTimerOn** and **ZTimerOff** .
;
; By Michael Abrash
;
mystack segment para stack ‘STACK’
mystack segment para stack ‘STACK'
db 512 dup(?)
mystack ends
;
Code segment para public ‘CODE’
Code segment para public ‘CODE'
assume cs:Code, ds:Code
extrnZTimerOn:near, ZTimerOff:near, ZTimerReport:near
Start proc near
@ -147,7 +147,7 @@ after the code in Listing 3.3 has been run.
;
call ZTimerOff
It’s worth noting that Listing 3.3 begins by jumping around the memory
It's worth noting that Listing 3.3 begins by jumping around the memory
variable **MemVar**. This approach lets us avoid reproducing Listing 3.2
in its entirety for each code fragment we want to measure; by defining
any needed data right in the code segment and jumping around that data,
@ -155,8 +155,8 @@ each listing becomes self-contained and can be plugged directly into
Listing 3.2 as TESTCODE. Listing 3.2 sets DS equal to CS before doing
anything else precisely so that data can be embedded in code fragments
being timed. Note that only after the initial jump is performed in
Listing 3.3 is the Zen timer started, since we don’t want to include the
execution time of start-up code in the timing interval. That’s why the
Listing 3.3 is the Zen timer started, since we don't want to include the
execution time of start-up code in the timing interval. That's why the
calls to **ZTimerOn** and **ZTimerOff** are in TESTCODE, not in
PZTEST.ASM; this way, we have full control over which portion of
TESTCODE is timed, and we can keep set-up code and the like out of the