Strip comments and inline ids onto h*

This commit is contained in:
James Gregory 2013-12-30 15:11:04 +11:00
commit 0f5f617adb
362 changed files with 2519 additions and 6694 deletions

View file

@ -10,16 +10,9 @@
<meta name="vspubdate" content="07/01/97" />
<meta name="vscategory" content="Web and Software Development: Game Development,Web and Software Development: Graphics and Multimedia Development" />
<title>Michael Abrash's Graphics Programming Black Book Special Edition: Unleashing the Pentium's</title><!-- HEADER -->
<!-- Empty Reference Subhead -->
<!--ISBN=1576101746//-->
<!--TITLE=Michael Abrash's Graphics Programming Black Book Special Edition//-->
<!--AUTHOR=Michael Abrash//-->
<!--PUBLISHER=The Coriolis Group, Inc.//-->
<title>Michael Abrash's Graphics Programming Black Book Special Edition: Unleashing the Pentium's</title>
<meta name="chapter" content="21" />
<meta name="pages" content="405-407" />
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
</head>
<body>
@ -39,11 +32,11 @@
<p>It&rsquo;s actually not hard to figure out which instructions go through which pipes; just back up until you find an instruction that can&rsquo;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&rsquo;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, <b>ADC, SBB</b>, and all other instructions not listed in Table 20.1 in the last chapter are likewise U-pipe markers.</p>
<h3><a id="Heading7"></a>Pentium Optimization in Action</h3>
<h3 id="Heading7">Pentium Optimization in Action</h3>
<p>Now, let&rsquo;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 endian-independent. This makes it easy to perform checksums on blocks of 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&rsquo;s hard to imagine that there&rsquo;s a lot of performance to be wrung from this snippet, right?</p>
<p><b>LISTING 21.1 L21-1.ASM</b></p><!-- CODE //-->
<p><b>LISTING 21.1 L21-1.ASM</b></p>
<pre>
; Calculates TCP/IP (16-bit carry-wrapping) checksum for buffer
; starting at ESI, of length ECX words.
@ -73,7 +66,7 @@ ckloop:
add esi,2 ;cycle 5 V-pipe
dec ecx ;cycle 6 U-pipe
jnz ckloop ;cycle 6 V-pipe
</pre><!-- END CODE //-->
</pre>
<p>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&rsquo;ll see why I say &ldquo;should take,&rdquo; not &ldquo;takes,&rdquo; shortly.) We should lose 2 cycles in each pipe to the two size prefixes (because the <b>ADD</b>s are 16-bit operations in a 32-bit segment), and another 2 cycles because of register contention that arises when <b>ADC AX,0</b> has to wait for the result of <b>ADD AX,[ESI]</b>. Then, too, even though <b>DEC</b> and <b>JNZ</b> can pair and the branch prediction for <b>JNZ</b> is presumably correct virtually all the time, they do take a full cycle, and maybe we can do something about that as well.</p>
@ -96,10 +89,6 @@ ckloop:
<div align="center">
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div><!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->
<!-- BEGIN SUB FOOTER -->
<!-- END FOOTER -->
</div>
</body>
</html>