Path: utzoo!utgpu!attcan!uunet!husc6!ukma!mailrus!cornell!uw-beaver!fluke!dcd From: dcd@tc.fluke.COM (David Dyck) Newsgroups: comp.os.minix Subject: Re: (IBM V1.3) tty1 performance? Really Virtual Memory for pc minix Summary: a VM for unix was posted already Keywords: virtual memory Message-ID: <6149@fluke.COM> Date: 29 Nov 88 22:47:19 GMT References: <5687@louie.udel.EDU> <760@sdcc15.ucsd.edu> Sender: news@tc.fluke.COM Organization: John Fluke Mfg. Co., Inc., Everett, WA Lines: 95 John J Marco had a suggestion: > ......... (An even better idea would be for > somebody to implement virtual memory for MINIX so that programs could > be as large as memory. This would be feasable with AT computers. XTs > would be quite slow, but at least they would run large programs. Back in Jan '88 MBECK@ai.ai.mit.edu (Mark E. Becker) posted a virtual memory for MINIX. Here is an excerpt from the header ---------------------------------------------------------------------- VM 1.0 A virtual memory subsystem John L. Connin 01/02/88 1.0 Introduction ----------------- VM is a virtual memory subsystem which effectively increases the available dynamically allocated data space (the heap) of application programs. One of the corner-stones of *nix, hence Minix, is that generally it is better to employ several small cooperative general purposes tools than one larger more dedicated tool. However, like everything else there are always exceptions (e.g. editors). Under Minix these larger tools can at times be constrained due to its small memory model (i.e. 64 KB code and 64 KB data) resulting from the segmented nature of the iAPX 86/88/186/286 microprocessor family. To overcome this memory constraint one could rewrite Minix based upon a larger memory model, a very messy proposition indeed, or implement a work-around. VM is such a work-around for increasing the effective data space beyond 64 kbytes. 1.1 Background Being a creature of habit, VM grew out of my desire to standardize on one sophisticated program editor environment that was accessible across different operating systems. To make a long story short, this objective lead me to select MicroEmacs as my editor of choice because (a) it is a very capable editor (b) the source code is readily available, and (c) it can be compiled on numerous operating systems -- including Minix. However, stock MicroEmacs (ME) on Minix can only accommodate a total of approximately 35 kbytes of edit text. This is because, like "Mined", the editor distributed with Minix, ME maintains all text in memory as a linked list of lines. To overcome this limit I explored several alternatives which converged to the virtual memory implementation contained herein. MicroEmacs Version 3.9e incorporating VM fits within 64 kbytes of code (when compiled with Microsoft C) and is capable of editing numerous files with an aggregate size of 500 kbytes plus. A high "want" in the VM design was to make its presence as transparent as possible within the host source code, and, of course, the user interface as well. I, simply, did not want to rewrite a lot of application code to hook-in a work-around. Frankly, the current VM's design exceeds my original expectation, and as a pleasant result, should be very portable to other applications. The implementation is original work but draws upon memory allocation code from Minix /fs/alloc.c. . . ... text deleted ... . . 6.0 Other ----------- VM was developed under MSDOS using Microsoft C V4.0 compiler. Minor compilation adjustments will likely be necessary with other environments including Minix. I trust others will find VM useful, and would appreciate feed back as to improvements and/or bug-fixes. However, this presents a problem since I do not have access to USENET. However I can be reached via regular mail at the following address: Vista Business Group, Inc. John L. Connin (305) 869-0567 105 Red Cedar Longwood, FL 32750 U.S.A. Enjoy... J.L. Connin ----------------------------------------------------------------------