Dec 242017
Displays important info about a TP 5.0 overlay structure.
File OVERSIZE.ZIP from The Programmer’s Corner in
Category Pascal Source Code
Displays important info about a TP 5.0 overlay structure.
File Name File Size Zip Size Zip Type
OVRSIZ.DOC 11356 4254 deflated
OVRSIZ.PAS 17468 4980 deflated

Download File OVERSIZE.ZIP Here

Contents of the OVRSIZ.DOC file

Overlay Size Analysis for Turbo Pascal 5
Version 1.0
Kim Kokkonen

Turbo Pascal 5.0 includes a nifty new overlay manager. Borland's OVERLAY unit
offers a sophisticated memory manager that does away with the need for the
programmer to specify overlay groups as required by Turbo Pascal 3.0's
overlays, and TurboPower Software's overlay manager for Turbo Pascal 4.0. The
new technique uses an overlay buffer of adjustable size, automatically loading
overlays into that area on demand, and overwriting old overlays in a manner
that minimizes reloading.

This technique is great for getting started with overlays, because it
minimizes the amount of information that the programmer needs to specify. When
it comes time to optimize the performance of an overlaid application, however,
the overlay manager doesn't provide enough information to allow the programmer
to answer the critical question: how large should the overlay buffer be?

That's why the OVRSIZ utility, supplied here, was developed. This little
program reads documented and undocumented information from an overlaid Turbo
Pascal 5.0 program, and writes a report that includes enough data to let the
programmer make an informed decision.

Running OVRSIZ
OVRSIZ is supplied in source form, so you'll first need to compile it to an
EXE file. OVRSIZ uses only the standard DOS unit.

To use OVRSIZ, first compile the overlaid application to create both an EXE
file and a corresponding MAP file. From within the TURBO integrated
environment, you enable a MAP file with the Options/Linker/Map File/Segments
menu. For the command line compiler, use the /GS option. OVRSIZ reads only the
first section of the MAP file (the segment map) to get certain information. It
doesn't hurt to have a detailed MAP file, but that takes more time and disk
space to store. OVRSIZ also reads from your EXE file to get detailed
information about the overlays. It doesn't need to access the OVR file.

Call OVRSIZ as follows:

OVRSIZ [Options] ProgName [>Output]

OVRSIZ forces the extension 'EXE' onto ProgName to open the executable file,
and the extension 'MAP' onto ProgName for the MAP file. The overlay report is
written to the standard output and may be redirected to a file or to the
printer. The only option at present is /Q, which stops OVRSIZ from writing
status messages while it works.

For test cases we've tried, OVRSIZ requires only a second or so to generate a
report. A megabyte application may take somewhat longer.

Using OVRSIZ Output
A little bit of background on TP5 overlays may be useful. Each overlaid unit
really has three parts: a static "dispatcher" segment, the actual overlaid
code, and a transient fixup table.

Each static dispatcher is a small code segment that's linked into the EXE
file. A unique dispatcher always remains in memory for each overlaid unit.
Whenever you call a procedure in an overlaid unit, you're really calling a
tiny (5 byte) routine in the static dispatcher. If the overlay is already
loaded into memory, the 5 byte "routine" is just a far jump instruction that
immediately transfers control to the real code in the overlay buffer. If the
overlay isn't currently loaded, the 5 bytes specify an INT 3Fh instruction and
one word of data. The INT 3Fh serves to transfer control to the OVERLAY unit,
which finds space for the overlay (perhaps by booting out other overlays),
loads the required overlay code into memory, patches direct jump instructions
into the static dispatcher, and jumps to the requested procedure. The data
word specifies the code offset of the routine being called and is used to
create the jump instruction.

The overlaid code itself is stored in the application's OVR file, which is
read by the overlay manager each time it must reload an overlay. If EMS
overlays are activated, the OVR file is read entirely into EMS during
initialization, and thereafter overlays are transferred to the overlay buffer
from EMS rather than disk.

The transient fixup tables are also stored in the OVR file, immediately
following the code for each unit. The overlay manager reads this information
into the overlay buffer each time an overlay is loaded. Fixup information is
used to correct intersegment references in the overlay code, based on the
starting address of the program. This information is "transient" because it's
used only when the overlay is being loaded; it doesn't retain space in the
overlay buffer thereafter.

The overlaid code size and the fixup table size are the two components that
affect the choice of an overlay buffer. The static dispatcher is always in
memory; from the viewpoint of optimization, it plays the role of fixed
overhead. It is interesting to note, however, that each dispatcher begins with
a 32 byte data area that describes the overlay. OVRSIZ reads much of the
information that it reports from this area.

We'll use the following example report to describe the OVRSIZ output.

Static Static Overlay Fixup Entry Overlay
Segment name Segment Size Size Size Points FilePos
============== ====== ===== ===== ===== ===== =======
TPENTRYDEMO 00000h 7248 - - - -
TPHELP 001C5h 256 8992 208 44 000004h
TPDOS 001D5h 896 - - - -
TPPICK 0020Dh 144 5760 144 20 0023E6h
TPMEMO 00216h 256 10592 128 44 003AF0h
TPENTRY 00226h 880 29312 528 167 0064C9h
TPWINDOW 0025Dh 320 5872 256 56 00D94Ah
TPCMD 00271h 1136 - - - -
TPMEMCHK 002B8h 160 - - - -

TPDATE 002C2h 240 3984 160 39 00F11Eh
DOS 002D1h 224 - - - -
TPMOUSE 002DFh 1248 - - - -
TPCRT 0032Dh 5792 - - - -
TPSTRING 00497h 3024 - - - -
OVERSET 00554h 112 - - - -
OVERLAY 0055Bh 1600 - - - -
SYSTEM 005BFh 6272 - - - -
DATA 00747h 50496 - - - -
STACK 0139Bh 16384 - - - -

Program segment prefix 256
Static code size 29808
Static data size 50496
Stack size 16384
Overlay buffer size 29840.. 65040
Total non-heap memory 126784..161984

The OVRSIZ report starts with a section that describes each segment in the
program, including both code and data. All but two of the lines correspond to
units used by the program. The last two lines specify the data and stack
segments. Segments are listed in order of increasing memory address.

The "Static Segment" column specifies the position in memory of each segment,
measured in hexadecimal paragraphs. Adding the base code segment of the
program (PrefixSeg+$10) to each segment will yield its physical memory address
at runtime.

"Static Size" is the decimal number of bytes used by each segment. For
non-overlaid units, this is the total amount of code left after smart linking.
For overlaid units, it is the size of the static dispatcher. The sum of the
static size column is the total static size of the program.

The remaining columns apply only to overlaid units; non-overlaid code, data,
and stack segments show just a dash here. The "Overlay Size" column specifies
the number of bytes required in the overlay buffer to load the code of the
unit. "Fixup Size" denotes the transient space required while loading the
overlay unit.

"Entry Points" specifies the number of 5 byte entries in each static
dispatcher. Although you might think that this would be the same as the number
of interfaced procedures and functions in the unit, that's not true. The
static dispatcher has an entry for _every_ procedure and function in the unit,
whether it's global or local, interfaced or hidden. The reason becomes clear
when you think about passing procedure parameters -- even a non-interfaced
routine can be called indirectly from outside of the unit, and the overlay
manager must still be informed when to load the code in such a case. The entry
points column thus provides a count of all the routines in a unit. (It also
adds one for the initialization block, if any.)

"Overlay FilePos" is the offset of the overlaid code segment within the
overlay file. The lowest number is always 4 because each overlay file starts
with a four byte signature.

OVRSIZ summarizes these details at the bottom of the report. A program's
memory usage consists of the static portions (PSP, static code, data, and
stack), plus the adjustable overlay buffer, plus the heap. TP5's overlay
manager requires that the overlay buffer be at least as large as the largest
unit's overlay code plus fixup space. This number is given in the left column
next to "Overlay buffer size". Clearly, there is no reason to make the overlay
buffer larger than the sum of _all_ the overlays plus the largest transient
fixup area. This total is given in the right column.

Heap space requirements cannot be determined using the analysis presented
here, so the bottom line specifies all required program memory except that for
the heap. The stack size reported is also just taken from the program's {$M}
directive (or the Turbo default of 16384). Appropriate optimization may allow
the stack size to be reduced as well.

If a specified set of overlaid units must reside in memory simultaneously (to
achieve adequate performance), then the overlay buffer should be at least as
large as the sum of the "Overlay Size" column for those units, plus the
largest "Fixup Size" for those units. If those units don't make calls to other
overlaid units, this will guarantee that the overlay manager loads them all at
once and doesn't kick one out to load the other.

The OVRSIZ report may also be used to see the payback from overlaying more
units or different units of a program.

Ultimately, specifying an optimum overlay buffer size requires intimate
knowledge of a program's behavior. With the information provided by OVRSIZE,
the programmer is armed with the data needed to make informed decisions.

About the Program
OVRSIZ was written by Kim Kokkonen of TurboPower Software. It is copyright (c)
1989 by TurboPower Software, all rights reserved. It may be distributed
freely, but not for a profit.

If you have problems, suggestions, or enhancements, contact me on CompuServe
ID [72457,2131] or at TurboPower Software:

TurboPower Software
P.O. Box 66747
Scotts Valley, CA 95066-0747

 December 24, 2017  Add comments

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>