jlowrey@skat.usc.edu (John 'Fritz' Lowrey) (03/21/91)
I am an experienced DOS programmer using C and PASCAL to create applications for myself and my office mates. Recently I have been porting a very large program from UNIX to the PC AT, this program when compiled with MSC 6.0 (max optimizations + exepack) is still very large and I would like to utilize overlays to reduce memory consumption for lesser used modules. The theory behind overlays and their implementation using the linker is not difficult. What I would like to know is: 1: Once the overlay module is no longer needed, is the memory allocated to it freed to the data segment? 2: In a related question, I assume procedures from one overlay module may call those in anther (which seems fairly inefficient, but logical), how is the memory for these overlay functions dealt with? Any clarifying responces would be appreciated. Fritz (jlowrey@skat.usc.edu)
joe@proto.com (Joe Huffman) (03/23/91)
jlowrey@skat.usc.edu (John 'Fritz' Lowrey) writes: > 1: Once the overlay module is no longer needed, is the memory > allocated to it freed to the data segment? Not with most overlay managers. The only one that I know of that does this is the one that comes with the Zortech C/C++ compiler called the 'V' (for virtual code) memory model. Actually the space for the overlay doesn't come from the data segment it comes from the heap and will be returned to the heap whenever malloc detects that a failure is about to occur. Also note that if malloc doesn't need the space the overlays may ALL be pulled into memory and once loaded there is virtually no overhead for calling functions residing in the overlays. Also important to note is that there are very few (zero?) overlay managers that support overlaying of data. All that I am aware of just overlay code. > 2: In a related question, I assume procedures from one overlay > module may call those in anther (which seems fairly > inefficient, but logical), how is the memory for these > overlay functions dealt with? Again it depends on the manager. With most managers you have to manually specify which modules may be resident simultaneously and where they reside. Calling a function that will reside on top of the caller can be bad news (reboot time). This is very difficult to test for because the call may only occur during some obscure condition or your code grows a bit more. The Zortech overlay scheme allows functions to call another other function safely (admittedly it slows down a bunch) even if it overlays itself. --- Zortech mailing list: send email to 'ztc-list-request@uunet.uu.net' with: Add: your-user-name@your-machine-name In the body of the message. --- Send Zortech bug reports to 'zortech-bugs@zortech.com' Send requests for educational discounts to 'zortech-ed@zortech.com' --- Zortech is my major source of income. Statements about them or their competitors cannot be totally without bias. -- joe@proto.com
bright@nazgul.UUCP (Walter Bright) (03/28/91)
In article <31248@usc> jlowrey@skat.usc.edu (John 'Fritz' Lowrey) writes:
/ The theory behind overlays and their implementation using the
/linker is not difficult. What I would like to know is:
I'll try to answer your questions as they apply to Zortech's VCM virtual
overlay system.
/ 1: Once the overlay module is no longer needed, is the memory
/ allocated to it freed to the data segment?
Yes. In fact, when a new overlay needs to be loaded, the VCM module actually
does call malloc. When malloc runs out of space, it calls VCM to try and
discard overlays until the malloc succeeds.
No separate swap buffer needs to be created for VCM.
/ 2: In a related question, I assume procedures from one overlay
/ module may call those in anther (which seems fairly
/ inefficient, but logical), how is the memory for these
/ overlay functions dealt with?
Yes, overlays may call each other in any way, including through function
pointers and through the virtual function table (for C++). Only one
overlay at a time *needs* to be resident, that is the one that is currently
executing. Other overlays are shuffled around as needed by malloc.
The complete source code to the VCM management routines is provided with
the Zortech Developer's Edition. For more information, call Zortech at
800-848-8408.