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

18
21-03.md
View file

@ -2,14 +2,14 @@
[Previous](21-02.html) [Table of Contents](index.html) [Next](21-04.html)
------------------------ --------------------------------- --------------------
It’s actually not hard to figure out which instructions go through which
pipes; just back up until you find an instruction that can’t pair or can
It's actually not hard to figure out which instructions go through which
pipes; just back up until you find an instruction that can't pair or can
only go through the U-pipe, and work forward from there, given the
knowledge that that instruction executes in the U-pipe. The easiest
thing to look for is branches. All branch target instructions execute in
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
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
instructions not listed in Table 20.1 in the last chapter are likewise
@ -17,7 +17,7 @@ U-pipe markers.
### Pentium Optimization in Action {#Heading7}
Now, let’s take a look at one of the simplest, tightest pieces of code
Now, let's take a look at one of the simplest, tightest pieces of code
imaginable, and see what our new Pentium perspective reveals. Listing
21.1 shows a loop implementing the TCP/IP checksum, a 16-bit checksum
that wraps carries around to the low bit so that the result is
@ -26,8 +26,8 @@ data regardless of the endian characteristics of the machines on which
those blocks are generated and received. (Thanks to fellow performance
enthusiast Terje Mathisen for suggesting this checksum as fertile ground
for Pentium optimization, in the ibm.pc/fast.code forum on Bix.) The
loop in Listing 21.1 consists of exactly five instructions; it’s hard to
imagine that there’s a lot of performance to be wrung from this snippet,
loop in Listing 21.1 consists of exactly five instructions; it's hard to
imagine that there's a lot of performance to be wrung from this snippet,
right?
**LISTING 21.1 L21-1.ASM**
@ -63,8 +63,8 @@ right?
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
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
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]**.
@ -78,7 +78,7 @@ 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
doesn’t cost anything, certainly not the one full cycle in each pipe
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