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: In the Lair of the Cycle-Eaters</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: In the Lair of the Cycle-Eaters</title>
<meta name="chapter" content="04" />
<meta name="pages" content="094-097" />
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
</head>
<body>
@ -41,7 +34,7 @@
<p>All in all, writing good assembler code is as much an art as a science. As a result, you should follow the rules of thumb described here&mdash;and then time your code to see how fast it really is. You should experiment freely, but always remember that actual, measured performance is the bottom line.</p>
<h4 align="left"><a id="Heading14"></a>Holding Up the 8088</h4>
<h4 align="left" id="Heading14">Holding Up the 8088</h4>
<p>In this chapter I&rsquo;ve taken you further and further into the depths of the PC, telling you again and again that you must understand the computer at the lowest possible level in order to write good code. At this point, you may well wonder, &ldquo;Have we gotten low enough?&rdquo;</p>
@ -53,7 +46,7 @@
<p>Let&rsquo;s start with DRAM refresh, which affects the performance of every program that runs on the PC.</p>
<h3><a id="Heading15"></a>Dynamic RAM Refresh: The Invisible Hand</h3>
<h3 id="Heading15">Dynamic RAM Refresh: The Invisible Hand</h3>
<p>Dynamic RAM (DRAM) refresh is sort of an act of God. By that I mean that DRAM refresh invisibly and inexorably steals a certain fraction of all available memory access time from your programs, when they are accessing memory for code and data. (When they are accessing cache on more recent processors, theoretically the DRAM refresh cycle-eater doesn&rsquo;t come into play, but there are other cycle-eaters waiting to prey on cache-bound programs.) While you <i>could</i> stop DRAM refresh, you wouldn&rsquo;t want to since that would be a sure prescription for crashing your computer. In the end, thanks to DRAM refresh, almost all code runs a bit slower on the PC than it otherwise would, and that&rsquo;s that.</p>
@ -61,7 +54,7 @@
<p>All of the PC&rsquo;s system memory consists of DRAM chips. Each DRAM chip in the PC must be completely refreshed about once every four milliseconds in order to ensure the integrity of the data it stores. Obviously, it&rsquo;s highly desirable that the memory in the PC retain the correct data indefinitely, so each DRAM chip in the PC <i>must</i> always be refreshed within 4 &micro;s of the last refresh. Since there&rsquo;s no guarantee that a given program will access each and every DRAM block once every 4 &micro;s, the PC contains special circuitry and programming for providing DRAM refresh.</p>
<h4 align="left"><a id="Heading16"></a>How DRAM Refresh Works in the PC</h4>
<h4 align="left" id="Heading16">How DRAM Refresh Works in the PC</h4>
<p>On the original 8088-based IBM PC, timer 1 of the 8253 timer chip is programmed at power-up to generate a signal once every 72 cycles, or once every 15.08&micro;s. That signal goes to channel 0 of the 8237 DMA controller, which requests the bus from the 8088 upon receiving the signal. (DMA stands for <i>direct memory access,</i> the ability of a device other than the 8088 to control the bus and access memory directly, without any help from the 8088.) As soon as the 8088 is between memory accesses, it gives control of the bus to the 8237, which in conjunction with special circuitry on the PC&rsquo;s motherboard then performs a single 4-cycle read access to 1 of 256 possible addresses, advancing to the next address on each successive access. (The read access is only for the purpose of refreshing the DRAM; the data that is read isn&rsquo;t used.)</p>
@ -69,9 +62,8 @@
<p>Don&rsquo;t sweat the details here. The important point is this: For at least 4 out of every 72 cycles, the original PC&rsquo;s bus is given over to DRAM refresh and is not available to the 8088, as shown in Figure 4.5. That means that as much as 5.56 percent of the PC&rsquo;s already inadequate bus capacity is lost. However, DRAM refresh doesn&rsquo;t necessarily stop the 8088 in its tracks for 4 cycles. The Execution Unit of the 8088 can keep processing while DRAM refresh is occurring, unless the EU needs to access memory. Consequently, DRAM refresh can slow code performance anywhere from 0 percent to 5.56 percent (and actually a bit more, as we'll see shortly), depending on the extent to which DRAM refresh occupies cycles during which the 8088 would otherwise be accessing memory.</p>
<p><a id="Fig5"><!-- </A><A HREF="javascript:displayWindow('images/04-05.jpg',407,339 )"> --><img src="images/04-05.jpg" /><br />
<!-- </A>
<BR><A HREF="javascript:displayWindow('images/04-05.jpg',407,339)"> --><b>Figure 4.5</b></a>&nbsp;&nbsp;<i>The PC bus dynamic RAM (DRAM) refresh.</i></p>
<p><a id="Fig5"><img src="images/04-05.jpg" /><br />
<b>Figure 4.5</b></a>&nbsp;&nbsp;<i>The PC bus dynamic RAM (DRAM) refresh.</i></p>
<p><br /></p>
@ -90,10 +82,6 @@
<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>