Change bold code snippets to inline code blocks
This commit is contained in:
parent
f658bfbb40
commit
3c76d884ef
185 changed files with 1772 additions and 1772 deletions
14
21-03.md
14
21-03.md
|
|
@ -19,7 +19,7 @@ the U-pipe, as do all instructions after conditional branches that fall
|
|||
through. Instructions with prefix bytes are generally good U-pipe
|
||||
markers, although they're expensive instructions that should be avoided
|
||||
whenever possible, and have at least one aberration with regard to pipe
|
||||
usage, as discussed below. Shifts, rotates, **ADC, SBB**, and all other
|
||||
usage, as discussed below. Shifts, rotates, `ADC, SBB`, and all other
|
||||
instructions not listed in Table 20.1 in the last chapter are likewise
|
||||
U-pipe markers.
|
||||
|
||||
|
|
@ -75,11 +75,11 @@ Wrong, wrong, wrong! As detailed in Listing 21.1, this loop should take
|
|||
6 cycles per checksummed word in 32-bit protected mode, a ridiculously
|
||||
high number for the Pentium. (You'll see why I say "should take," not
|
||||
"takes," shortly.) We should lose 2 cycles in each pipe to the two size
|
||||
prefixes (because the **ADD**s are 16-bit operations in a 32-bit
|
||||
prefixes (because the `ADD`s are 16-bit operations in a 32-bit
|
||||
segment), and another 2 cycles because of register contention that
|
||||
arises when **ADC AX,0** has to wait for the result of **ADD AX,[ESI]**.
|
||||
Then, too, even though **DEC** and **JNZ** can pair and the branch
|
||||
prediction for **JNZ** is presumably correct virtually all the time,
|
||||
arises when `ADC AX,0` has to wait for the result of `ADD AX,[ESI]`.
|
||||
Then, too, even though `DEC` and `JNZ` can pair and the branch
|
||||
prediction for `JNZ` is presumably correct virtually all the time,
|
||||
they do take a full cycle, and maybe we can do something about that as
|
||||
well.
|
||||
|
||||
|
|
@ -87,11 +87,11 @@ The first thing to do is to time the code in Listing 21.1 to verify our
|
|||
analysis. When I unleashed the Zen timer on Listing 21.1, I found, to my
|
||||
surprise, that the code actually takes only five cycles per checksum
|
||||
word processed, not six. A little more experimentation revealed that
|
||||
adding a size prefix to the two-cycle **ADD EAX,[ESI]** instruction
|
||||
adding a size prefix to the two-cycle `ADD EAX,[ESI]` instruction
|
||||
doesn't cost anything, certainly not the one full cycle in each pipe
|
||||
that a prefix is supposed to take. More experimentation showed that
|
||||
prefix bytes do cost the documented extra cycle when used with one-cycle
|
||||
instructions such as **MOV**. At this point, my preliminary conclusion
|
||||
instructions such as `MOV`. At this point, my preliminary conclusion
|
||||
is that prefixes can pair with the first cycle of at least some
|
||||
multiple-cycle instructions. Determining exactly why this happens will
|
||||
take further research on my part, but the most important conclusion is
|
||||
|
|
|
|||
Loading…
Reference in a new issue