Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
10
20-02.html
10
20-02.html
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=20//-->
|
||||
<!--PAGES=386-390//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -36,7 +36,7 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">V-Pipe-Capable Instructions</FONT></H3>
|
||||
<H3><A NAME="Heading4"></A>V-Pipe-Capable Instructions</H3>
|
||||
<P>Any instruction can go through the U-pipe, and, for practical purposes, the U-pipe is always executing instructions. (The exceptions are when the U-pipe execution unit is waiting for instruction or data bytes after a cache miss, and when a U-pipe instruction finishes before a paired V-pipe instruction, as I’ll discuss below.) Only the instructions shown in Table 20.1 can go through the V-pipe. In addition, the V-pipe can execute a separate instruction only when one of the instructions listed in Table 20.2 is executing in the U-pipe; superscalar execution is not possible while any instruction not listed in Table 20.2 is executing in the U-pipe. So, for example, if you use <B>SHR EDX,CL</B>, which takes 4 cycles to execute, no other instructions can execute during those 4 cycles; if, on the other hand, you use <B>SHR EDX,10</B>, it will take 1 cycle to execute in the U-pipe, and another instruction can potentially execute concurrently in the V-pipe. (As you can see, similar instruction sequences can have vastly different performance characteristics on the Pentium.)</P>
|
||||
<P>Basically, after the current instruction or pair of instructions is finished (that is, once neither the U- nor V-pipe is executing anything), the Pentium sends the next instruction through the U-pipe. If the instruction after the one in the U-pipe is an instruction the V-pipe can handle, if the instruction in the U-pipe is pairable, and if register contention doesn’t occur, then the V-pipe starts executing that instruction, as shown in Figure 20.2. Otherwise, the second instruction waits until the first instruction is done, then executes in the U-pipe, possibly pairing with the next instruction in line if all pairing conditions are met.</P>
|
||||
<HR><!-- CODE //-->
|
||||
|
|
@ -126,7 +126,7 @@ ROL/ROR/RCL/RCR reg,1 (1 cycle)
|
|||
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><SMALL><I>A fundamental rule of Pentium optimization is that it pays to break complex instructions into equivalent simple instructions, then shuffle the simple instructions for maximum use of the V-pipe. This is true partly because most of the pairable instructions are simple instructions, and partly because breaking instructions into pieces allows more freedom to rearrange code to avoid the AGIs and register contention I’ll discuss in the next chapter.</I></SMALL>
|
||||
</TABLE>
|
||||
<P><A NAME="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/20-02.jpg',405,144 )"> --><IMG SRC="images/20-02.jpg"><BR><!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-02.jpg',405,144)"> --><FONT COLOR="#000077"><B>Figure 20.2</B></FONT></A> <I>Instruction flow through the two pipes.</I>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-02.jpg',405,144)"> --><B>Figure 20.2</B></A> <I>Instruction flow through the two pipes.</I>
|
||||
</P>
|
||||
<P>One downside of this “RISCification” (turning complex instructions into simple, RISC-like ones) of Pentium-optimized code is that it makes for substantially larger code. For example,
|
||||
</P>
|
||||
|
|
@ -144,7 +144,7 @@ push eax
|
|||
</PRE>
|
||||
<!-- END CODE SNIP //-->
|
||||
<P><A NAME="Fig3"><!-- </A><A HREF="javascript:displayWindow('images/20-03.jpg',409,210 )"> --><IMG SRC="images/20-03.jpg"><BR><!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-03.jpg',409,210)"> --><FONT COLOR="#000077"><B>Figure 20.3</B></FONT></A> <I>Pushing a value from memory effectively in one cycle.</I>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-03.jpg',409,210)"> --><B>Figure 20.3</B></A> <I>Pushing a value from memory effectively in one cycle.</I>
|
||||
</P>
|
||||
<P>A more telling example is the following
|
||||
</P>
|
||||
|
|
@ -178,7 +178,7 @@ mov [MemVar],edx
|
|||
|
||||
<hr width="90%" size="1" noshade>
|
||||
<div align="center">
|
||||
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
</div>
|
||||
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
||||
<!-- reference_subfoot = footer -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue