home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PASCAL / OVRSIZE.ZIP / OVRSIZ.DOC next >
Encoding:
Text File  |  1993-01-04  |  11.1 KB  |  209 lines
  1.                   Overlay Size Analysis for Turbo Pascal 5
  2.                                 Version 1.0
  3.                                 Kim Kokkonen
  4.  
  5. Overview
  6. -----------------------------------------------------------------------------
  7. Turbo Pascal 5.0 includes a nifty new overlay manager. Borland's OVERLAY unit
  8. offers a sophisticated memory manager that does away with the need for the
  9. programmer to specify overlay groups as required by Turbo Pascal 3.0's
  10. overlays, and TurboPower Software's overlay manager for Turbo Pascal 4.0. The
  11. new technique uses an overlay buffer of adjustable size, automatically loading
  12. overlays into that area on demand, and overwriting old overlays in a manner
  13. that minimizes reloading.
  14.  
  15. This technique is great for getting started with overlays, because it
  16. minimizes the amount of information that the programmer needs to specify. When
  17. it comes time to optimize the performance of an overlaid application, however,
  18. the overlay manager doesn't provide enough information to allow the programmer
  19. to answer the critical question: how large should the overlay buffer be?
  20.  
  21. That's why the OVRSIZ utility, supplied here, was developed. This little
  22. program reads documented and undocumented information from an overlaid Turbo
  23. Pascal 5.0 program, and writes a report that includes enough data to let the
  24. programmer make an informed decision.
  25.  
  26.  
  27. Running OVRSIZ
  28. -----------------------------------------------------------------------------
  29. OVRSIZ is supplied in source form, so you'll first need to compile it to an
  30. EXE file. OVRSIZ uses only the standard DOS unit.
  31.  
  32. To use OVRSIZ, first compile the overlaid application to create both an EXE
  33. file and a corresponding MAP file. From within the TURBO integrated
  34. environment, you enable a MAP file with the Options/Linker/Map File/Segments
  35. menu. For the command line compiler, use the /GS option. OVRSIZ reads only the
  36. first section of the MAP file (the segment map) to get certain information. It
  37. doesn't hurt to have a detailed MAP file, but that takes more time and disk
  38. space to store. OVRSIZ also reads from your EXE file to get detailed
  39. information about the overlays. It doesn't need to access the OVR file.
  40.  
  41. Call OVRSIZ as follows:
  42.  
  43.   OVRSIZ [Options] ProgName [>Output]
  44.  
  45. OVRSIZ forces the extension 'EXE' onto ProgName to open the executable file,
  46. and the extension 'MAP' onto ProgName for the MAP file. The overlay report is
  47. written to the standard output and may be redirected to a file or to the
  48. printer. The only option at present is /Q, which stops OVRSIZ from writing
  49. status messages while it works.
  50.  
  51. For test cases we've tried, OVRSIZ requires only a second or so to generate a
  52. report. A megabyte application may take somewhat longer.
  53.  
  54.  
  55. Using OVRSIZ Output
  56. -----------------------------------------------------------------------------
  57. A little bit of background on TP5 overlays may be useful. Each overlaid unit
  58. really has three parts: a static "dispatcher" segment, the actual overlaid
  59. code, and a transient fixup table.
  60.  
  61. Each static dispatcher is a small code segment that's linked into the EXE
  62. file. A unique dispatcher always remains in memory for each overlaid unit.
  63. Whenever you call a procedure in an overlaid unit, you're really calling a
  64. tiny (5 byte) routine in the static dispatcher. If the overlay is already
  65. loaded into memory, the 5 byte "routine" is just a far jump instruction that
  66. immediately transfers control to the real code in the overlay buffer. If the
  67. overlay isn't currently loaded, the 5 bytes specify an INT 3Fh instruction and
  68. one word of data. The INT 3Fh serves to transfer control to the OVERLAY unit,
  69. which finds space for the overlay (perhaps by booting out other overlays),
  70. loads the required overlay code into memory, patches direct jump instructions
  71. into the static dispatcher, and jumps to the requested procedure. The data
  72. word specifies the code offset of the routine being called and is used to
  73. create the jump instruction.
  74.  
  75. The overlaid code itself is stored in the application's OVR file, which is
  76. read by the overlay manager each time it must reload an overlay. If EMS
  77. overlays are activated, the OVR file is read entirely into EMS during
  78. initialization, and thereafter overlays are transferred to the overlay buffer
  79. from EMS rather than disk.
  80.  
  81. The transient fixup tables are also stored in the OVR file, immediately
  82. following the code for each unit. The overlay manager reads this information
  83. into the overlay buffer each time an overlay is loaded. Fixup information is
  84. used to correct intersegment references in the overlay code, based on the
  85. starting address of the program. This information is "transient" because it's
  86. used only when the overlay is being loaded; it doesn't retain space in the
  87. overlay buffer thereafter.
  88.  
  89. The overlaid code size and the fixup table size are the two components that
  90. affect the choice of an overlay buffer. The static dispatcher is always in
  91. memory; from the viewpoint of optimization, it plays the role of fixed
  92. overhead. It is interesting to note, however, that each dispatcher begins with
  93. a 32 byte data area that describes the overlay. OVRSIZ reads much of the
  94. information that it reports from this area.
  95.  
  96. We'll use the following example report to describe the OVRSIZ output.
  97.  
  98. UNIT STATISTICS
  99.                 Static  Static  Overlay  Fixup   Entry   Overlay
  100. Segment name   Segment    Size    Size    Size  Points   FilePos
  101. ==============  ======   =====   =====   =====   =====   =======
  102. TPENTRYDEMO     00000h    7248       -       -       -        -
  103. TPHELP          001C5h     256    8992     208      44   000004h
  104. TPDOS           001D5h     896       -       -       -        -
  105. TPPICK          0020Dh     144    5760     144      20   0023E6h
  106. TPMEMO          00216h     256   10592     128      44   003AF0h
  107. TPENTRY         00226h     880   29312     528     167   0064C9h
  108. TPWINDOW        0025Dh     320    5872     256      56   00D94Ah
  109. TPCMD           00271h    1136       -       -       -        -
  110. TPMEMCHK        002B8h     160       -       -       -        -
  111. TPDATE          002C2h     240    3984     160      39   00F11Eh
  112. DOS             002D1h     224       -       -       -        -
  113. TPMOUSE         002DFh    1248       -       -       -        -
  114. TPCRT           0032Dh    5792       -       -       -        -
  115. TPSTRING        00497h    3024       -       -       -        -
  116. OVERSET         00554h     112       -       -       -        -
  117. OVERLAY         0055Bh    1600       -       -       -        -
  118. SYSTEM          005BFh    6272       -       -       -        -
  119. DATA            00747h   50496       -       -       -        -
  120. STACK           0139Bh   16384       -       -       -        -
  121.  
  122. Program segment prefix     256
  123. Static code size         29808
  124. Static data size         50496
  125. Stack size               16384
  126. Overlay buffer size      29840.. 65040
  127.                         ==============
  128. Total non-heap memory   126784..161984
  129.  
  130.  
  131. The OVRSIZ report starts with a section that describes each segment in the
  132. program, including both code and data. All but two of the lines correspond to
  133. units used by the program. The last two lines specify the data and stack
  134. segments. Segments are listed in order of increasing memory address.
  135.  
  136. The "Static Segment" column specifies the position in memory of each segment,
  137. measured in hexadecimal paragraphs. Adding the base code segment of the
  138. program (PrefixSeg+$10) to each segment will yield its physical memory address
  139. at runtime.
  140.  
  141. "Static Size" is the decimal number of bytes used by each segment. For
  142. non-overlaid units, this is the total amount of code left after smart linking.
  143. For overlaid units, it is the size of the static dispatcher. The sum of the
  144. static size column is the total static size of the program.
  145.  
  146. The remaining columns apply only to overlaid units; non-overlaid code, data,
  147. and stack segments show just a dash here. The "Overlay Size" column specifies
  148. the number of bytes required in the overlay buffer to load the code of the
  149. unit. "Fixup Size" denotes the transient space required while loading the
  150. overlay unit.
  151.  
  152. "Entry Points" specifies the number of 5 byte entries in each static
  153. dispatcher. Although you might think that this would be the same as the number
  154. of interfaced procedures and functions in the unit, that's not true. The
  155. static dispatcher has an entry for _every_ procedure and function in the unit,
  156. whether it's global or local, interfaced or hidden. The reason becomes clear
  157. when you think about passing procedure parameters -- even a non-interfaced
  158. routine can be called indirectly from outside of the unit, and the overlay
  159. manager must still be informed when to load the code in such a case. The entry
  160. points column thus provides a count of all the routines in a unit. (It also
  161. adds one for the initialization block, if any.)
  162.  
  163. "Overlay FilePos" is the offset of the overlaid code segment within the
  164. overlay file. The lowest number is always 4 because each overlay file starts
  165. with a four byte signature.
  166.  
  167. OVRSIZ summarizes these details at the bottom of the report. A program's
  168. memory usage consists of the static portions (PSP, static code, data, and
  169. stack), plus the adjustable overlay buffer, plus the heap. TP5's overlay
  170. manager requires that the overlay buffer be at least as large as the largest
  171. unit's overlay code plus fixup space. This number is given in the left column
  172. next to "Overlay buffer size". Clearly, there is no reason to make the overlay
  173. buffer larger than the sum of _all_ the overlays plus the largest transient
  174. fixup area. This total is given in the right column.
  175.  
  176. Heap space requirements cannot be determined using the analysis presented
  177. here, so the bottom line specifies all required program memory except that for
  178. the heap. The stack size reported is also just taken from the program's {$M}
  179. directive (or the Turbo default of 16384). Appropriate optimization may allow
  180. the stack size to be reduced as well.
  181.  
  182. If a specified set of overlaid units must reside in memory simultaneously (to
  183. achieve adequate performance), then the overlay buffer should be at least as
  184. large as the sum of the "Overlay Size" column for those units, plus the
  185. largest "Fixup Size" for those units. If those units don't make calls to other
  186. overlaid units, this will guarantee that the overlay manager loads them all at
  187. once and doesn't kick one out to load the other.
  188.  
  189. The OVRSIZ report may also be used to see the payback from overlaying more
  190. units or different units of a program.
  191.  
  192. Ultimately, specifying an optimum overlay buffer size requires intimate
  193. knowledge of a program's behavior. With the information provided by OVRSIZE,
  194. the programmer is armed with the data needed to make informed decisions.
  195.  
  196.  
  197. About the Program
  198. -----------------------------------------------------------------------------
  199. OVRSIZ was written by Kim Kokkonen of TurboPower Software. It is copyright (c)
  200. 1989 by TurboPower Software, all rights reserved. It may be distributed
  201. freely, but not for a profit.
  202.  
  203. If you have problems, suggestions, or enhancements, contact me on CompuServe
  204. ID [72457,2131] or at TurboPower Software:
  205.  
  206.   TurboPower Software
  207.   P.O. Box 66747
  208.   Scotts Valley, CA 95066-0747
  209.