184 lines
9.3 KiB
HTML
184 lines
9.3 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<META name=vsisbn content="1576101746">
|
|
<META name=vstitle content="Michael Abrash's Graphics Programming Black Book, Special Edition">
|
|
<META name=vsauthor content="Michael Abrash">
|
|
<META name=vspublisher content="The Coriolis Group">
|
|
<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.//-->
|
|
<!--CHAPTER=21//-->
|
|
<!--PAGES=402-405//-->
|
|
<!--UNASSIGNED1//-->
|
|
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
|
|
|
<CENTER>
|
|
<TABLE BORDER>
|
|
<TR>
|
|
<TD><A HREF="21-01.html">Previous</A></TD>
|
|
<TD><A HREF="index.html">Table of Contents</A></TD>
|
|
<TD><A HREF="21-03.html">Next</A></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CENTER>
|
|
<P><BR></P>
|
|
</P>
|
|
<P>As on the 486, you should keep a careful eye out for AGIs involving the stack pointer. Implicit modifiers of ESP, such as <B>PUSH</B> and <B>POP</B>, are special-cased so you don’t have to worry about AGIs. However, if you explicitly modify ESP with this instruction</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
sub esp,100h
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>for example, or with the popular
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov esp,ebp
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>you can then get AGIs if you attempt to use ESP to address memory, either explicitly with instructions like this one
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
moveax,[esp+20h]
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>or via <B>PUSH</B>, <B>POP</B>, or other instructions that implicitly use ESP as an addressing register.</P>
|
|
<P>On the 486, any instruction that had both a constant value and an addressing displacement, such as</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov dword ptr [ebp+16],1
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>suffered a 1-cycle penalty, taking a total of 2 cycles. Such instructions take only one cycle on the Pentium, but they cannot pair, so they’re still the most expensive sort of <B>MOV</B>. Knowing this can speed up something as simple as zeroing two memory variables, as in</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
sub eax,eax ;U-pipe 1
|
|
;any V-pipe pairable
|
|
; instruction can go here,
|
|
; or SUB could be in V-pipe
|
|
mov [MemVar1],eax ;U-pipe 2
|
|
mov [MemVar2],eax ;V-pipe 2
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>which should never be slower and should potentially be 0.5 cycles faster, and six bytes smaller than this sequence:
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov [MemVar1],0 ;U-pipe 1
|
|
mov [MemVar2],0 ;U-pipe 2
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>Note, however, that my experiments thus far indicate that the two writes in the first case don’t actually pair (possibly because the memory variables have never been read into the internal cache), so you might want to insert an instruction between the two <B>MOV</B>s—and, of course, this is yet another reason why you should always measure your code’s actual performance.</P>
|
|
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Register Contention</FONT></H3>
|
|
<P>Finally, we come to the last major component of superscalar optimization: register contention. The basic premise here is simple: You can’t use the same register in two inherently sequential ways in a single cycle. For example, you can’t execute
|
|
</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
inc eax ;U-pipe cycle 1
|
|
;V-pipe idle cycle 1
|
|
; due to dependency
|
|
and ebx,eax ;U-pipe cycle 2
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>in a single cycle; <B>AND EBX,EAX</B> can’t execute until the value in EAX is known, and that can’t happen until <B>INC EAX</B> is done. Consequently, the V-pipe idles while <B>INC EAX</B> executes in the U-pipe. We saw this in the last chapter when we discussed splitting instructions into simple instructions, and it is by far the most common sort of register contention, known as read-after-write register contention. Read-after-write register contention is the primary reason we have to interleave independent operations in order to get maximum V-pipe usage.</P>
|
|
<P>The other sort of register contention is known as write-after-write. Write-after-write register contention happens when two instructions try to write to the same register on the same cycle. While that may not seem like a particularly useful operation in general, it can happen when subregisters are being set, as in the following</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
sub eax,eax ;U-pipe cycle 1
|
|
;V-pipe idle cycle 1
|
|
; due to register contention
|
|
mov al,[Var] ;U-pipe cycle 2
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>where an attempt is made to set both EAX and its AL subregister on the same cycle. Write-after-write contention implies that the two instructions comprising the above substitute for <B>MOVZX</B> should have at least one unrelated instruction between them when <B>SUB EAX,EAX</B> executes in the V-pipe.</P>
|
|
<H4 ALIGN="LEFT"><A NAME="Heading5"></A><FONT COLOR="#000077">Exceptions to Register Contention</FONT></H4>
|
|
<P>Intel has special-cased some very useful exceptions to register contention. Happily, write-after-read operations do <I>not</I> cause contention. Such operations, as in</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov eax,edx ;U-pipe cycle 1
|
|
sub edx,edxX ;V-pipe cycle 1
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>are free of charge.
|
|
</P>
|
|
<P>Also, stack-related instructions that modify ESP only implicitly (without ESP as part of any explicit operand) do not cause AGIs, and neither do they cause register contention with other instructions that use ESP only implicitly; such instructions include <B>PUSH <I>reg/immed</I>, POP <I>reg</I></B>, and <B>CALL</B>. (However, these instructions do cause register contention on ESP—but not AGIs—with instructions that use ESP explicitly, such as <B>MOV EAX,[ESP+4]</B>.) Without this special case, the following sequence would hardly use the V-pipe at all:</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
mov eax,[MemVar] ;U-pipe cycle 1
|
|
push esi ;V-pipe cycle 1
|
|
push eax ;U-pipe cycle 2
|
|
push edi ;V-pipe cycle 2
|
|
push ebx ;U-pipe cycle 3
|
|
call FooTilde ;V-pipe cycle 3
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>But in fact, all the instructions pair, even though ESP is modified five times in the space of six instructions.
|
|
</P>
|
|
<P>The final register-contention special case is both remarkable and remarkably important. There is exactly one sort of instruction that can pair only in the V-pipe: branches. Any near call or conditional or unconditional near jump can execute in the V-pipe paired with any pairable U-pipe instruction, as illustrated by this sequence:</P>
|
|
<!-- CODE SNIP //-->
|
|
<PRE>
|
|
LoopTop:
|
|
mov [esi],eax ;U-pipe cycle 1
|
|
add esi,4 ;V-pipe cycle 1
|
|
dec ecx ;U-pipe cycle 2
|
|
jnz LoopTop ;V-pipe cycle 2
|
|
</PRE>
|
|
<!-- END CODE SNIP //-->
|
|
<P>Branches can’t pair in the U-pipe; a branch that executes in the U-pipe runs alone, with the V-pipe idle. If a call or jump is correctly predicted by the Pentium’s branch prediction circuitry (as discussed in the last chapter), it executes in a single cycle, pairing if it runs in the V-pipe; if mispredicted, conditional jumps take 4 cycles in the U-pipe and 5 cycles in the V-pipe, and mispredicted calls and unconditional jumps take 3 cycles in either pipe. Note that <B>RET</B> can’t pair.</P>
|
|
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">Who’s in First?</FONT></H3>
|
|
<P>One of the trickiest things about superscalar optimization is that a given instruction stream can execute at a different speed depending on the pipe where it starts execution, because which instruction goes through the U-pipe first determines which of the following instructions will be able to pair. If we take the last example and add one more instruction, the other instructions will go through different pipes than previously, and cause the loop as a whole to take 50 percent longer, even though we only added 25 percent more cycles:
|
|
</P>
|
|
<!-- CODE //-->
|
|
<PRE>
|
|
LoopTop:
|
|
inc edx ;U-pipe cycle 1
|
|
mov [esi],eax ;V-pipe cycle 1
|
|
add esi,4 ;U-pipe cycle 2
|
|
dec ecx ;V-pipe cycle 2
|
|
jnz LoopTop ;U-pipe cycle 3
|
|
;V-pipe idle cycle 3
|
|
; because JNZ can’t
|
|
; pair in the U-pipe
|
|
</PRE>
|
|
<!-- END CODE //-->
|
|
<P><BR></P>
|
|
<CENTER>
|
|
<TABLE BORDER>
|
|
<TR>
|
|
<TD><A HREF="21-01.html">Previous</A></TD>
|
|
<TD><A HREF="index.html">Table of Contents</A></TD>
|
|
<TD><A HREF="21-03.html">Next</A></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CENTER>
|
|
|
|
<hr width="90%" size="1" noshade>
|
|
<div align="center">
|
|
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
|
</div>
|
|
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
|
<!-- reference_subfoot = footer -->
|
|
<!-- reference_footer = subfoot -->
|
|
|
|
<!-- BEGIN SUB FOOTER -->
|
|
</BODY>
|
|
</HTML>
|
|
|
|
<!-- END FOOTER -->
|
|
|
|
|