Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
James Gregory
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
10
20-03.html
10
20-03.html
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=20//-->
|
||||
<!--PAGES=390-393//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -36,20 +36,20 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Lockstep Execution</FONT></H3>
|
||||
<H3><A NAME="Heading5"></A>Lockstep Execution</H3>
|
||||
<P>You may wonder why anyone would bother breaking <B>ADD [MemVar],EAX</B> into three instructions, given that this instruction can go through either pipe with equal ease. The answer is that while the memory-accessing instructions other than <B>MOV, PUSH</B>, and <B>POP</B> listed in Table 20.1 (that is, <B>INC/DEC [<I>mem</I>], ADD/SUB/XOR/AND/OR/CMP/ADC/SBB <I>reg</I>,[<I>mem</I>]</B>, and <B>ADD/SUB/XOR/AND/OR/CMP/ADC/SBB [<I>mem</I>],<I>reg/immed</I></B>) can be paired, they do not provide the 100 percent overlap that we seek. If you look at Tables 20.1 and 20.2, you will see that instructions taking from 1 to 3 cycles can pair. However, any pair of instructions goes through the two pipes in lockstep. This means, for example, that if <B>ADD [EBX],EDX</B> is going through the U-pipe, and <B>INC EAX</B> is going through the V-pipe, the V-pipe will be idle for 2 of the 3 cycles that the U-pipe takes to execute its instruction, as shown in Figure 20.4. Out of the theoretical 6 cycles of work that can be done during this time, we actually get only 4 cycles of work, or 67 percent utilization. Even though these instructions pair, then, this sequence fails to make maximum use of the Pentium’s horsepower.</P>
|
||||
<P>The key here is that when two instructions pair, both execution units are tied up until both instructions have finished (which means at least for the amount of time required for the longer of the two to execute, plus possibly some extra cycles for pairable instructions that can’t fully overlap, as described below). The logical conclusion would seem to be that we should strive to pair instructions of the same lengths, but that is often not correct.</P>
|
||||
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><SMALL><I>The actual rule is that we should strive to pair one-cycle instructions (or, at most, two-cycle instructions, but not three-cycle instructions), which in turn leads to the corollary that we should, in general, use mostly one-cycle instructions when optimizing.</I></SMALL>
|
||||
</TABLE>
|
||||
<P><A NAME="Fig4"><!-- </A><A HREF="javascript:displayWindow('images/20-04.jpg',411,224 )"> --><IMG SRC="images/20-04.jpg"><BR><!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-04.jpg',411,224)"> --><FONT COLOR="#000077"><B>Figure 20.4</B></FONT></A> <I>Lockstep execution and idle time in the V-pipe.</I>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-04.jpg',411,224)"> --><B>Figure 20.4</B></A> <I>Lockstep execution and idle time in the V-pipe.</I>
|
||||
</P>
|
||||
<P>Here’s why. The Pentium is fully capable of handling instructions that use memory operands in either pipe, or, if necessary, in both pipes at once. Each pipe has its own write FIFO, which buffers the last few writes and takes care of writing the data out while the Pentium continues processing. The Pentium also has a write-back internal data cache, so data that is frequently changed doesn’t have to be written to external memory (which is much slower than the cache) very often. This combination means that unless you write large blocks of data at a high speed, the Pentium should be able to keep up with both pipes’ memory writes without stalling execution.
|
||||
</P>
|
||||
<P>The Pentium is also designed to satisfy both pipes’ needs for reading memory operands with little waiting. The data cache is constructed so that both pipes can read from the cache <I>on the same cycle</I>. This feat is accomplished by organizing the data cache as eight-banked memory, as shown in Figure 20.5, with each 32-byte cache line consisting of 8 dwords, 1 in each bank. The banks are independent of one another, so as long as the desired data is in the cache and the U- and V-pipes don’t try to read from the same bank on the same cycle, both pipes can read memory operands on the same cycle. (If there is a cache bank collision, the V-pipe instruction stalls for one cycle.)</P>
|
||||
<P>Normally, you won’t pay close attention to which of the eight dword banks your paired memory accesses fall in—that’s just too much work—but you might want to watch out for simultaneously read addresses that have the same values for address</P>
|
||||
<P><A NAME="Fig5"><!-- </A><A HREF="javascript:displayWindow('images/20-05.jpg',409,162 )"> --><IMG SRC="images/20-05.jpg"><BR><!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-05.jpg',409,162)"> --><FONT COLOR="#000077"><B>Figure 20.5</B></FONT></A> <I>The Pentium’s eight bank data cache.</I>
|
||||
<BR><A HREF="javascript:displayWindow('images/20-05.jpg',409,162)"> --><B>Figure 20.5</B></A> <I>The Pentium’s eight bank data cache.</I>
|
||||
</P>
|
||||
<P>bits 2, 3, and 4 (fall in the same bank) in tight loops, and you should also avoid sequences like
|
||||
</P>
|
||||
|
|
@ -97,7 +97,7 @@ add edi,[DestinationSkip] ;V-pipe cycles 1 and 2
|
|||
|
||||
<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