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

Remove colour attributes from body and strip most of the font tags out

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
Download patch file Download diff file Expand all files Collapse all files

6
04-03.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=04//-->
<!--PAGES=084-087//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -85,7 +85,7 @@ mov dx,word ptr [MemVar]
<P>There is yet another reason why register operands are preferable to memory operands, and it&rsquo;s an unexpected effect of the 8-bit bus cycle-eater. Instructions with only register operands tend to be shorter (in terms of bytes) than instructions with memory operands, and when it comes to performance, shorter is usually better. In order to explain why that is true and how it relates to the 8-bit bus cycle-eater, I must diverge for a moment.</P>
<P>For the last few pages, you may well have been thinking that the 8-bit bus cycle-eater, while a nuisance, doesn&rsquo;t seem particularly subtle or difficult to quantify. After all, any instruction reference tells us exactly how many cycles each instruction loses to the 8-bit bus cycle-eater, doesn&rsquo;t it?</P>
<P>Yes and no. It&rsquo;s true that in general we know approximately how much longer a given instruction will take to execute with a word-sized memory operand than with a byte-sized operand, although the dynamic RAM refresh and wait state cycle-eaters (which I&rsquo;ll cover a little later) can raise the cost of the 8-bit bus cycle-eater considerably. However, <I>all</I> word-sized memory accesses lose 4 cycles to the 8-bit bus cycle-eater, and there&rsquo;s one sort of word-sized memory access we haven&rsquo;t discussed yet: instruction fetching. The ugliest manifestation of the 8-bit bus cycle-eater is in fact the prefetch queue cycle-eater.</P>
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">The Prefetch Queue Cycle-Eater</FONT></H3>
<H3><A NAME="Heading9"></A>The Prefetch Queue Cycle-Eater</H3>
<P>In an 8088 context, here&rsquo;s the prefetch queue cycle-eater in a nutshell: The 8088&rsquo;s 8-bit external data bus keeps the Bus Interface Unit from fetching instruction bytes as fast as the 16-bit Execution Unit can execute them, so the Execution Unit often lies idle while waiting for the next instruction byte to be fetched.
</P>
<P>Exactly why does this happen? Recall that the 8088 is an 8086 internally, but accesses word-sized memory data at only one-half the maximum rate of the 8086 due to the 8088&rsquo;s 8-bit external data bus. Unfortunately, instructions are among the word-sized data the 8086 fetches, meaning that the 8088 can fetch instructions at only one-half the speed of the 8086. On the other hand, the 8086-equivalent Execution Unit of the 8088 can <I>execute</I> instructions every bit as fast as the 8086. The net result is that the Execution Unit burns up instruction bytes much faster than the Bus Interface Unit can fetch them, and ends up idling while waiting for instructions bytes to arrive.</P>
@ -121,7 +121,7 @@ shr ax,1
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->