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

Merge pull request #4 from mstum/master

Browse source 
Chapter 1-3 corrections
This commit is contained in:
James Gregory 2014-01-28 00:46:46 -08:00
commit a17b3067ed
3 changed files with 88 additions and 88 deletions
Download patch file Download diff file Expand all files Collapse all files

10
src/chapter-01.md
View file

@ -254,7 +254,7 @@ requires over two and one-half minutes to checksum *one* file!
These results make it clear that it's folly to rely on your compiler's These results make it clear that it's folly to rely on your compiler's
optimization to make your programs fast. Listing 1.1 is simply poorly optimization to make your programs fast. Listing 1.1 is simply poorly
designed, and no amount of compiler optimization will compensate for designed, and no amount of compiler optimization will compensate for
that failing. To drive home the point, conListings 1.2 and 1.3, which that failing. To drive home the point, Listings 1.2 and 1.3, which
together are equivalent to Listing 1.1 except that the entire checksum together are equivalent to Listing 1.1 except that the entire checksum
loop is written in tight assembly code. The assembly language loop is written in tight assembly code. The assembly language
implementation is indeed faster than any of the C versions, as shown in implementation is indeed faster than any of the C versions, as shown in
@ -419,7 +419,7 @@ Listing 1.1.
How can we speed up Listing 1.1? It should be clear that we must somehow How can we speed up Listing 1.1? It should be clear that we must somehow
avoid invoking DOS for every byte in the file, and that means reading avoid invoking DOS for every byte in the file, and that means reading
more than one byte at a time, then buffering the data and parceling it more than one byte at a time, then buffering the data and parceling it
out for examination one byte at a time. By gosh, that's a description of out for examination one byte at a time. My gosh, that's a description of
C's stream I/O feature, whereby C reads files in chunks and buffers the C's stream I/O feature, whereby C reads files in chunks and buffers the
bytes internally, doling them out to the application as needed by bytes internally, doling them out to the application as needed by
reading them from memory rather than calling DOS. Let's try using stream reading them from memory rather than calling DOS. Let's try using stream
@ -500,7 +500,7 @@ your programs that directly affect response time. Notice, for example,
that I haven't bothered to implement a version of the checksum program that I haven't bothered to implement a version of the checksum program
entirely in assembly; Listings 1.2 and 1.6 call assembly subroutines entirely in assembly; Listings 1.2 and 1.6 call assembly subroutines
that handle the time-critical operations, but C is still used for that handle the time-critical operations, but C is still used for
checking command-line parameters, operning files, printing, and the checking command-line parameters, opening files, printing, and the
like. like.
> ![](images/i.jpg) > ![](images/i.jpg)
@ -521,7 +521,7 @@ Listing 1.4 is good, but let's see if there are other—perhaps less
obvious—ways to get the same results faster. Let's start by considering obvious—ways to get the same results faster. Let's start by considering
why Listing 1.4 is so much better than Listing 1.1. Like `read()`, why Listing 1.4 is so much better than Listing 1.1. Like `read()`,
`getc()` calls DOS to read from the file; the speed improvement of `getc()` calls DOS to read from the file; the speed improvement of
Listing 1.4 over Listing 1.1 occurs because `getc()` eads many bytes Listing 1.4 over Listing 1.1 occurs because `getc()` reads many bytes
at once via DOS, then manages those bytes for us. That's faster than at once via DOS, then manages those bytes for us. That's faster than
reading them one at a time using `read()`—but there's no reason to reading them one at a time using `read()`—but there's no reason to
think that it's faster than having our program read and manage blocks think that it's faster than having our program read and manage blocks
@ -667,7 +667,7 @@ indeed make a significant difference. Table 1.1 indicates that the
optimized version of Listing 1.5 produced by Microsoft C outperforms an optimized version of Listing 1.5 produced by Microsoft C outperforms an
unoptimized version of the same code by more than 60 percent. What's unoptimized version of the same code by more than 60 percent. What's
more, a mostly-assembly version of Listing 1.5, shown in Listings 1.6 more, a mostly-assembly version of Listing 1.5, shown in Listings 1.6
and 1.7, outperforms even the best-optimized C version of List1.5 by 26 and 1.7, outperforms even the best-optimized C version of Listing 1.5 by 26
percent. These are considerable improvements, well worth pursuing—once percent. These are considerable improvements, well worth pursuing—once
the design has been maxed out. the design has been maxed out.

2
src/chapter-02.md
View file

@ -200,7 +200,7 @@ enough.
The single most critical aspect of the hardware, and the one about which The single most critical aspect of the hardware, and the one about which
it is hardest to learn, is the CPU. The x86 family CPUs have a complex, it is hardest to learn, is the CPU. The x86 family CPUs have a complex,
irregular instruction set, and, unlike most processors, they are neither irregular instruction set, and, unlike most processors, they are neither
straightforward nor wellregarding true code performance. What's more, straightforward nor well-documented true code performance. What's more,
assembly is so difficult to learn that most articles and books that assembly is so difficult to learn that most articles and books that
present assembly code settle for code that just works, rather than code present assembly code settle for code that just works, rather than code
that pushes the CPU to its limits. In fact, since most articles and that pushes the CPU to its limits. In fact, since most articles and

44
src/chapter-03.md
View file

@ -671,7 +671,7 @@ count reaches zero, the timer turns over and starts counting down again
without stopping, and a pulse is generated for a single clock period. without stopping, and a pulse is generated for a single clock period.
While the pulse is not held for nearly as long as in square wave mode, While the pulse is not held for nearly as long as in square wave mode,
it doesn't matter, since the 8259 interrupt controller is configured in it doesn't matter, since the 8259 interrupt controller is configured in
the PC to be edgeand hence cares only about the existence of a pulse the PC to be edge-triggered and hence cares only about the existence of a pulse
from timer 0, not the duration of the pulse. As a result, timer 0 from timer 0, not the duration of the pulse. As a result, timer 0
continues to generate timer interrupts in divide-by-N mode, and the continues to generate timer interrupts in divide-by-N mode, and the
system clock continues to maintain good time. system clock continues to maintain good time.
@ -688,7 +688,7 @@ the Zen timer shown in Listing 3.1 supports.
In fact, the Zen timer shown in Listing 3.1 can only time intervals of In fact, the Zen timer shown in Listing 3.1 can only time intervals of
up to about 54 ms in length, since that is the period of time that can up to about 54 ms in length, since that is the period of time that can
be measured by timer 0 before its count turns over and repeats. be measured by timer 0 before its count turns over and repeats.
fifty-four ms may not seem like a very long time, but even a CPU as slow Fifty-four ms may not seem like a very long time, but even a CPU as slow
as the 8088 can perform more than 1,000 divides in 54 ms, and division as the 8088 can perform more than 1,000 divides in 54 ms, and division
is the single instruction that the 8088 performs most slowly. If a is the single instruction that the 8088 performs most slowly. If a
measured period turns out to be longer than 54 ms (that is, if timer 0 measured period turns out to be longer than 54 ms (that is, if timer 0
@ -730,10 +730,10 @@ restart until the timing interval ends, losing time all the while.
The effects on the system time of the Zen timer aren't a matter for The effects on the system time of the Zen timer aren't a matter for
great concern, as they are temporary, lasting only until the next warm great concern, as they are temporary, lasting only until the next warm
or cold boot. System that have batteryclocks, (AT-style machines; that or cold boot. System that have battery-backed clocks, (AT-style machines; that
is, virtually all machines in common use) automatically reset the is, virtually all machines in common use) automatically reset the
correct time whenever the computer is booted, and systems without correct time whenever the computer is booted, and systems without
battery-clocks prompt for the correct date and time when booted. battery-backed clocks prompt for the correct date and time when booted.
Also, repeated use of the Zen timer usually makes the system clock slow Also, repeated use of the Zen timer usually makes the system clock slow
by at most a total of a few seconds, unless code that takes much longer by at most a total of a few seconds, unless code that takes much longer
than 54 ms to run is timed (in which case the Zen timer will notify you than 54 ms to run is timed (in which case the Zen timer will notify you
@ -789,8 +789,8 @@ from timer counts to microseconds, and prints the resulting time in
microseconds to the standard output. microseconds to the standard output.
Note that `ZTimerReport` need not be called immediately after Note that `ZTimerReport` need not be called immediately after
`ZTimerOff`. In fact, after a given call to `ZTimerOff, `ZTimerOff`. In fact, after a given call to `ZTimerOff`,
ZTimerReport` can be called at any time right up until the next call to `ZTimerReport` can be called at any time right up until the next call to
`ZTimerOn`. `ZTimerOn`.
You may want to use the Zen timer to measure several portions of a You may want to use the Zen timer to measure several portions of a
@ -880,7 +880,7 @@ performance will be similar even on different IBM models; in fact, quite
the opposite is true. For example, every PS/2 computer, even the 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 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 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 *Zen of Assembly Language* on an XT-compatible computer, 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 differences were minor, mind you, but my experience illustrates the risk
of assuming that a specific make of computer will perform in a certain of assuming that a specific make of computer will perform in a certain
@ -1111,8 +1111,8 @@ pztime <filename>
In fact, that's exactly how I timed each of the listings in this book. In fact, that's exactly how I timed each of the listings in this book.
Code fragments you write yourself can be timed in just the same way. If Code fragments you write yourself can be timed in just the same way. If
you wish to time code directly in place in your programs, rather than in you wish to time code directly in place in your programs, rather than in
the test-bed program of Listing 3.2, simply insert calls to `ZTimerOn, the test-bed program of Listing 3.2, simply insert calls to `ZTimerOn`,
ZTimerOff`, and `ZTimerReport` in the appropriate places and link `ZTimerOff`, and `ZTimerReport` in the appropriate places and link
PZTIMER to your program. PZTIMER to your program.
### The Long-Period Zen Timer ### The Long-Period Zen Timer
@ -1303,7 +1303,7 @@ computers.
; All registers and all flags are preserved by all routines. ; All registers and all flags are preserved by all routines.
; ;
Code segment word public ‘CODE' Code segment word public 'CODE'
assume cs:Code, ds:nothing assume cs:Code, ds:nothing
public ZTimerOn, ZTimerOff, ZTimerReport public ZTimerOn, ZTimerOff, ZTimerReport
@ -1384,10 +1384,10 @@ ReferenceCount dw ? ;number of counts required to
; String printed to report results. ; String printed to report results.
; ;
OutputStr label byte OutputStr label byte
db 0dh, 0ah, ‘Timed count: ‘ db 0dh, 0ah, 'Timed count: '
TimedCountStr db 10 dup (?) TimedCountStr db 10 dup (?)
db ' microseconds', 0dh, 0ah db ' microseconds', 0dh, 0ah
db ‘$' db '$'
; ;
; Temporary storage for timed count as it's divided down by powers ; Temporary storage for timed count as it's divided down by powers
; of ten when converting from doubleword binary to ASCII. ; of ten when converting from doubleword binary to ASCII.
@ -1417,7 +1417,7 @@ PowersOfTenEnd labelword
; ;
TurnOverStr label byte TurnOverStr label byte
db 0dh, 0ah db 0dh, 0ah
db ‘****************************************************' db '****************************************************'
db 0dh, 0ah db 0dh, 0ah
db '* Either midnight passed or an hour or more passed *' db '* Either midnight passed or an hour or more passed *'
db 0dh, 0ah db 0dh, 0ah
@ -1429,11 +1429,11 @@ TurnOverStrlabelbyte
db 0dh, 0ah db 0dh, 0ah
db '* run to be timed by the long-period Zen timer. *' db '* run to be timed by the long-period Zen timer. *'
db 0dh, 0ah db 0dh, 0ah
db ‘* Suggestions: use the DOS TIME command, the DOS *' db '* Suggestions: use the DOS TIME command, the DOS *'
db 0dh, 0ah db 0dh, 0ah
db ‘* time function, or a watch. *' db '* time function, or a watch. *'
db 0dh, 0ah db 0dh, 0ah
db ‘****************************************************' db '****************************************************'
db 0dh, 0ah db 0dh, 0ah
db '$' db '$'
@ -1896,7 +1896,7 @@ substantially.
Finally, please note that the *precision* Zen timer works perfectly well Finally, please note that the *precision* Zen timer works perfectly well
on both PS/2 and non-PS/2 computers. The PS/2 and 8253 considerations on both PS/2 and non-PS/2 computers. The PS/2 and 8253 considerations
we've just discussed apply *only* to the longZen timer. we've just discussed apply *only* to the long-period Zen timer.
### Example Use of the Long-Period Zen Timer ### Example Use of the Long-Period Zen Timer
@ -2126,7 +2126,7 @@ be dealt with here: small code model and large; I'll tackle the simpler
one, the small code model, first. one, the small code model, first.
Altering the Zen timer for linking to a small code model C program Altering the Zen timer for linking to a small code model C program
involves the following steps: `C` hange `ZTimerOn` to involves the following steps: Change `ZTimerOn` to
`_ZTimerOn`, change `ZTimerOff` to `_ZTimerOff`, change `_ZTimerOn`, change `ZTimerOff` to `_ZTimerOff`, change
`ZTimerReport` to `_ZTimerReport`, and change `Code` to `ZTimerReport` to `_ZTimerReport`, and change `Code` to
`_TEXT` . Figure 3.2 shows the line numbers and new states of all `_TEXT` . Figure 3.2 shows the line numbers and new states of all
@ -2190,13 +2190,13 @@ call near ptr ReferenceZTimerOn
(and likewise for `ReferenceZTimerOff`), which works because (and likewise for `ReferenceZTimerOff`), which works because
`ReferenceZTimerOn` is in the same segment as the calling code. This `ReferenceZTimerOn` is in the same segment as the calling code. This
is normally a great optimization, being both smaller and faster than a is normally a great optimization, being both smaller and faster than a
far call. However, it's not so great for the Zen far call.
![**Figure 3.3**  *Changes for use with large code model C.*](images/03-03.jpg) ![**Figure 3.3**  *Changes for use with large code model C.*](images/03-03.jpg)
timer, because our purpose in calling the reference timing code is to However, it's not so great for the Zen timer, because our purpose in calling the reference timing code is to
determine exactly how much time is taken by overhead code—including the determine exactly how much time is taken by overhead code—including the
far calls to `ZTimerOn` and `ZTimerOf`f! By converting the far calls far calls to `ZTimerOn` and `ZTimerOf`! By converting the far calls
to push/near call pairs within the Zen timer module, TASM makes it to push/near call pairs within the Zen timer module, TASM makes it
impossible to emulate exactly the overhead of the Zen timer, and makes impossible to emulate exactly the overhead of the Zen timer, and makes
timings slightly (about 16 cycles on a 386) less accurate. timings slightly (about 16 cycles on a 386) less accurate.
@ -2255,7 +2255,7 @@ processor cache at the start of the code being timed, because the timing
code is not necessarily fetched and does not necessarily access memory code is not necessarily fetched and does not necessarily access memory
in exactly the same time sequence as the code immediately preceding the in exactly the same time sequence as the code immediately preceding the
code under measurement normally does. This prefetch effect can introduce code under measurement normally does. This prefetch effect can introduce
as much as 3 to 4 µ of inaccuracy. Similarly, the state of the prefetch as much as 3 to 4 µs of inaccuracy. Similarly, the state of the prefetch
queue at the end of the code being timed affects how long the code that queue at the end of the code being timed affects how long the code that
stops the timer takes to execute. Consequently, the Zen timer tends to stops the timer takes to execute. Consequently, the Zen timer tends to
be more accurate for longer code sequences, since the relative magnitude be more accurate for longer code sequences, since the relative magnitude