US 5,063,499 AGrant

Method for a Correlating Virtual Memory Systems by Redirecting Access for Used Stock Instead of Supervisor Stock During Normal Supervisor Mode Processing

Issue Date:1991-11-05

•11 Claims

•10 Drawing Sheets

Abstract

A method for causing suitably configured versions of the Apple Macintosh computer running the Apple Macintosh operating system to operate in user mode while causing at least user programs to continue to perform as though operating in supervisor mode, and in conjunction therewith a further method for implementing virtual memory on such Apple Macintosh computer systems.

Metadata

Assignee

Connectix, Inc.

Inventor

Jonathan F. Garber

Application Information

Application Number:US 2948311

Filing Date:1989-01-09

Priority Date:1989-01-09

Art Unit:232

Classifications

IPC:

G06F 1202

Field of Search:

364200 MS File;900 MS File

Patent Drawings (10 sheets)

Description

FIELD OF THE INVENTION

This invention relates to virtual memory systems for computers, and more particularly relates to virtual memory systems for microprocessor-based computers using the Motorola 680X0 series microprocessor and the Apple Macintosh operating system.

BACKGROUND OF THE INVENTION

Virtual memory has long been known for use with mainframe computers and minicomputers. Virtual memory basically refers to a technique for combining a quantity of physical memory, typically provided by semiconductor chips such as DRAM, with a block of peripheral storage, which has in the past usually been magnetic media-based storage such as a hard disk, to give to the computer user the impression that the amount of physical RAM is actually larger than the available physical RAM.

The advantages of such techniques are well known in the art. Certain of these advantages are particularly noteworthy at present, including the substantial cost and relative unavailability of DRAM memory as compared to hard disk memory, as well as nominal space and power requirements, and nonvolatility.

A variety of virtual memory algorithms are known. Most use a memory management unit of some sort which maps a memory address in the virtual address space either to physical RAM or to the peripheral storage. One such algorithm is referred to as "paging", in which the virtual address space is divided into pages, and pages of information are swapped between the physical RAM and the peripheral storage. Various algorithms also exist for determining when best to make such a page swap. One common approach is to swap pages on demand.

Shown in FIG. 1a is a simplified prior art implementation of virtual memory. As can be seen, when the system detects an attempted access to a location of memory not resident in physical RAM, it saves the state of the processor on the stack, swaps in the page of virtual memory containing the necessary information, retrieves from the stack the state of the processor, and proceeds to execute the instruction that accessed the virtual space.

Although such virtual memory techniques are well known, such techniques generally have not been applied in the microcomputer-based, personal computer environment. Thus, for example, virtual memory has not been used in the Apple Macintosh/Macintosh SE/ Macintosh II environment with the Macintosh operating system. These environments may, in general, be thought of as Motorola 68XXX-based microcomputers using the Apple Macintosh operating system. Other operating systems offered by Apple, for example A/UX, and certain other manufacturers, such as Sun Microsystems, for example, use different operating systems, for example UNIX, with the same classes of microprocessors and offer virtual memory in such different environments.

The Motorola 680X0 series of microprocessors are designed to have two modes of operation, usually referred to as supervisor mode and user mode. To implement virtual memory, user programs generally are not permitted to operate with the 680X0 microprocessor in supervisor mode. Instead, only the operating system and operating system calls may run the processor in supervisor mode, while user programs operate only in user mode.

A difficulty arises with the Apple Macintosh series of personal computers using 680X0 microprocessors, because the Macintosh operating system permits user programs to operate the 680X0 processor in supervisor mode. A key difficulty which results is that the user programs for the Macintosh computer, operating with the 680X0 processor in supervisor mode, may change the location of the supervisor stack. FIG. 1b is a simplified block diagram of the arrangement of physical memory in a conventional Apple Macintosh computer, showing the operating system zone at the lowest addresses in memory, followed by a zone of memory for application programs. Above the zone for application programs is a stack zone, which in conventional Apple Macintosh computers is a supervisor-mode stack zone. Finally, at the top of memory is a zone referred to as static memory, where application programs can reserve a specific portion of memory to store needed information, and the information in those addresses generally cannot be moved by other programs until the system is rebooted.

Since most, if not all, virtual memory systems save the state of thprocessor to a stack, permitting the user program to alter the location of the supervisor stack while at the same time trying to run virtual memory may mean that the supervisor stack is moved, by the user program in supervisor mode, to a location which the virtual memory system already has swapped out to disk. When an attempt is later made to save the processor state on the stack, the state of the processor is effectively lost, resulting in a fatal error.

Thus, while the Macintosh operating system has many attractive features, including a popular graphics capability and user-friendly interface, the limitations of the Apple Macintosh operating system have posed significant problems for users desiring more memory and the associated performance improvements. Thus, there has been a significant need for a virtual memory system which is transparent to the normal user of the Apple Macintosh operating system with Apple Macintosh computers using the 680X0 processor.

SUMMARY OF THE INvENTION

The present invention overcomes the limitations of the prior art by implementing a page-swapping virtual memory algorithm for the Apple MacIntosh series of computers having add-on or internal MMU functions and suitable disk space. The disk space, although typically a magnetic media hard disk, also can be provided by a floppy disk, tape drive, optical disk, or other suitable form of storage media.

Stated simplistically, the present invention fools the Apple Macintosh operating system into believing that the system and all applications running under the system are operating in supervisor mode. In fact, however, the system and the applications are operating at most times in user mode. In this manner, the stack address can be carefully controlled, and located where it will not be swapped out by the virtual memory algorithm. In this manner page swaps to the virtual address space can be readily performed for less critical information.

More specifically, the present invention interposes a software layer of virtual memory code between hardware and the operating system. The present invention therefore runs above the operating system and user programs. The process of the present invention then recognizes when the processor tries to execute an instruction not available in the unprivileged user mode, and performs a software emulation of that instruction. The emulation may either be a specially written emulator, such as might be desirable for certain common instructions, or execution of the instruction in supervisor mode under close scrutiny.

Additionally, the process of the present invention intercepts other operations which might corrupt the state of the stack pointer, and relocates to the appropriate new location, such as a user stack, the information sought by or left from those operations. In some situations, user programs may attempt to alter the addresses used to perform such intercepts. Such difficulties are avoided by forcing the routine to alter a different address, permitting the original vector exception table to be left intact. The appropriate jump may then be made after the process evaluates the requested exception.

To permit the present invention to be implemented on an Apple Macintosh II computer using a Motorola 68020 microprocessor, a memory management chip such as the Motorola 68851 PMMU must be added to the system. A socket for such a chip s provided on the currently available Macintosh II. Shown in FIG. 1c is a simplified hardware schematic showing the interposing of a PMMU chip between the 68020 CPU and memory such as is found in the Apple Macintosh II computers.

In addition, the process of the present invention operates Apple Macintosh computers using the Motorola 68030 microprocessor and running under the Macintosh operating system, since the 68030 internally provides the memory management features necessary for operation of the present invention.

To implement the present invention on existing models of the Macintosh line which use a 68000 processor, such as the Macintosh SE, Macintosh Plus, Macintosh 512E, and others, it is necessary to add a 680X0 processor other than a 68000. Numerous accelerator boards for these Macintosh computers offer just such capability, and use either a 68010, 68012, 68020 or 68030 processor as well as providing a slot for a Motorola 68851 MMU. As with the Macintosh II, an MMU must also be added (unless a 68030 processor is added) to permit the Macintosh SE and Plus computers to run the present invention.

It is therefore one object of the present invention to provide a process for implementing a virtual memory algorithm on an Apple Macintosh computer having a 680X0 processor and operating under the Macintosh operating system.

It is another object of the present invention to provide a process by which an Apple Macintosh computer operating in user mode under the Apple Macintosh operating system emulates an Apple Macintosh computer operating in supervisor mode under the Apple Macintosh operating system.

Still another object of the present invention is to provide a process by which instructions normally processed by an Apple Macintosh computer in supervisor mode can be emulated by an Apple Macintosh computer in user mode.

It is a further object of the present invention to provide a virtual memory system which is substantially transparent to the user of Apple Macintosh computers having 680X0 processors running under the Macintosh operating system.

It is a further object of the present invention to provide a virtual memory system capable of modifying the Apple Macintosh operating system to require user programs to operate with the 680X0 microprocessor in user mode as opposed to supervisor mode.

It is another object of the present invention to provide a process layered between the hardware and the operating system of the Macintosh computer which permits operation of a hard disk to provide virtual memory.

Another object of the present invention is to provide a method of warm booting a Macintosh computer running the Macintosh operating system which prevents resetting of a memory management unit and permits operation of a virtual memory algorithm.

It is yet another object of the present invention to provide a method for ensuring that no page fault occurs during time critical operations.

Still another object of the present invention is to provide a method partitioning I/O operations into blocks small enough to be processed in the amount of available physical memory.

A still further object of the present invention is to provide a method for performing an initialization which permits a virtual memory system to be automatically installed in an Apple Macintosh computer which permits slot devices and drivers to install in apparently normal fashion but within the virtual memory space.

These and other objects of the present invention will be more apparent from the following Detailed Description of the Invention, taken in conjunction with the figures described below.

THE FIGURES

FIG. 1a is a simplified view of a prior art approach to virtual memory.

FIG. 1b is a prior art view, in block diagram form, of the memory arrangement of a Macintosh computer running the Macintosh operating system.

FIG. 1c is a prior art view of a computer system, such as the Apple Macintosh II, having a 68020 microprocessor, a 68851 MMU, and memory.

FIG. 2a is a flow diagram showing the installation of the process of the present invention upon initialization of a suitably configured Apple Macintosh computer system.

FIG. 2b is a block diagram view of the memory arrangement of a Macintosh computer running the present invention with the Macintosh operating system.

FIG. 3 is a flow diagram showing the process of the present invention by which exception vectors may be re-routed.

FIG. 4 is a flow diagram of the process of the present invention directed to emulating execution of privileged instructions.

FIG. 5 is a flow diagram of the process of the present invention which permits certain privileged instructions to run in supervisor mode under close scutiny, or supervision.

FIG. 6 is a flow diagram of the process of the present invention directed to handling unimplemented instruction traps, referred to as line 1010 system calls, within the Macintosh operating system.

FIG. 7 is a flow diagram of the process of the present invention for permitting the Macintosh operating system and programs executing under it to run with virtual memory in 32-bit mode as well as 24-bit mode.

FIG. 8 is a flow diagram of the process of the present invention for handling page swaps between the physical RAM and the virtual address space.

FIG. 9 is a flow diagram of the process of the present invention for permitting the system to handle "double page faults" which can occur when an interrupt generates a page fault while a page fault is already in progress.

FIG. 10 is a flow diagram describing the process by which the present invention selects pages of physical RAM to be swapped out to disk.

FIGS. 11a-11b, taken together, are a flow diagram showing a "read" optimization routine in the present invention for transferring information from the virtual address space to physical RAM in anticipation of need.

DETAILED DESCRIPTION OF THE INVENTION

The process of the present invention basically is comprised of several routines which cooperate to permit implementation of a virtual memory algorithm on a suitably configured Macintosh computer running under the Macintosh operating system. As noted above, a suitably configured Macintosh must include a 680X0 processor other than the 68000, MMU functions, and a suitable storage media such as a hard disk or other comparable device. With all but the 68030 processor, such MMU functions can be provided by adding a 68851 PMMU chip.

With the exception of the installation and page swap routines, each of these routines may generally be referred to as a "patch" which fixes a problem the Macintosh operating system trying to run a virtual memory algorithm would otherwise have. The routines which comprise the process of the present invention can generally be referred to as the INITIALIZATION ROUTINE (FIG. 2a), the RE-VECTORING PATCH (FIG. 3), the PRIVILEGE VIOLATION PATCH (FIG. 4), the TRACE PATCH (FIG. 5), the LINE 1010 VECTOR PATCH (FIG. 6), the SWAP MMU MODE PATCH (FIG. 7), the BUS ERROR VECTOR (FIGS. 8 and 9), the PAGE SELECTION ROUTINE (FIG. 10), the READ PATCH (FIGS. 11a-22b), and the WRITE PATCH, which is substantially identical to the READ PATCH.

INITIALIZATION ROUTINE

The INITIALIZATION ROUTINE, indicated generally at 10, is called at system startup by the Macintosh operating system. More specifically, the program by which the process of the present invention is implemented is copied into the system folder (or system directory) of the suitably configured Apple Macintosh computer. Then, on the next boot of the system, the program of the present invention is started by the system in the normal course of booting, as shown at step 10. The INITIALIZATION ROUTINE of the present invention thereupon checks, at step 20, to determine whether the proper hardware (a 68020 processor with a PMMU, a 68030, or other processor offering comparable functionality) and software (the Macintosh operating system or comparable) is present. If the proper hardware/software environment is not present, or upon user request, initialization is bypassed at step 14, typically without halting the system. The user may bypass installation by, for example, holding down the escape key during boot.

If the proper environment does exist, the initialization continues at step 16 by determining whether the software of the present invention has already been initialized once since power was turned on. This step is significant in the operation of the process of the present invention. Because the operating system loads into memory first at power up, the virtual memory process of the present invention initially runs under the operating system. By appropriate selection of the program name, such as by using a space as the initial character in the name, the process of the present invention will attempt to initialize, or install, immediately following boot by the operating system and prior to allowing other programs to initialize.

The software of the present invention installs itself by defining the virtual memory space and setting the PMMU and then, as will be discussed in greater detail hereinafter, restarts the operating system by a warm re-boot. The restart, or re-boot, is limited and is prohibited from incorrectly updating the values of the address at the top of memory, the buffer pointer address, or any part of the PMMU configuration registers. Since the virtual memory space and the critical memory settings are already defined, following the reboot the operating system runs in the virtual memory space set up by the first pass of the present invention, and runs under the present invention. The operating system then restarts the virtual memory process of the present invention, which detects that it has already initialized once since power up, and that the virtual memory space is available. The remainder of the installation can then be completed as discussed below. This "stutter start" technique (starting once normally, and then performing a controlled restart of the operating system under the virtual memory process) has been found to assist in providing a substantially transparent implementation of a virtual memory system on an Apple Macintosh II or similar computer.

Assuming the software implementing the present invention has not already been initialized, the process inquires at step 18 whether the virtual memory software has ever (not just on this pass) been installed on this machine before. If not, a virtual address space is allocated from the disk at step 20. In a preferred embodiment, the disk space allocated at step 20 is contiguous, although it is not necessary in all instances that the disk space be contiguous. In addition, with the present release of the Macintosh operating system, only eight megabytes of RAM can be recognized by the operating system, and thus only eight megabytes are allocated at step 20. However, it is anticipated that such limitations will be removed from the operating system, in which case step 20 may be readily modified to include selection of the amount of virtual memory space desired, which can then exceed eight megabytes. In addition, for performance reasons discussed below, the amount of disk space allocated is presently more than just the amount required to supplement the physical memory to eight megabytes, so that a copy of all data stored in physical RAM can also be maintained on disk. This increases performance by, among other things, avoiding the need to write to disk when swapping out unused pages.

Whether the allocation of disk space was successful is determined at step 22. If the allocation was not successful, installation is bypassed at step 24. However, in most cases where sufficient free hard disk space exists, the allocation will be successful. At this point, the disk space is allocated, which was the purpose of the installation inquiry at step 18, and so the two paths converge. Of course, even if the virtual memory system of the present invention has been installed on this machine before, if the previously allocated space has been corrupted or discarded since that installation, the present invention will simply proceed as though no prior installation had occurred.

Following successful allocation of the disk space, the code which implements the present invention is copied at step 26 from the disk to a known location in physical memory. In some embodiments it may be desirable to oopy the oode to a fixed location in physical memory, although this is not always necessary. At a later time, the locations holding this code can be remapped to the top (highest address) of logical memory and locked (made immune to page swapping, described in greater detail hereinafter) to ensure that no portion of the code is swapped out to disk. The process then determines how much physical RAM exists, and determines how much to emulate before reaching the current limit of eight megabytes noted above. Although the present version of the Macintosh OS includes an eight megabyte limit, step 28 may also include selection of the amount of memory to emulate. Once the eight megabyte limit of the operating system is removed, the user may then size the virtual memory in accordance with the available space on the hard disk.

Following the determination of how much virtual memory will be created, page translation tables are created at step 30. In a typical embodiment, a single table entry is made for each page of virtual memory. The tables are used by the 68851 PMMU (FIG. 1c) to address the physical and disk based, or peripheral, portions of the virtual memory space. The tables are then initialized to recognize the existing amount of physical RAM, starting at address 0, followed by the allocated amount of disk-based virtual memory, starting with the next address following the physical RAM. Such disk-based virtual memory is alternatively referred to herein as "non-resident", or "paged out" memory.

Following creation of the page translation tables, a portion (for example, half or other suitable portion) of physical memory is typically remapped at step 32 to the top of the virtual address space. A logical zone for the startup system stack is then created by remapping a suitable number of pages [for example, on the order of four 2K byte pages mapped at the very top of the virtual address space, although the exact number of pages can be increased substantially to avoid any possible overflow] to a zone at the halfway point between logical address and the top of virtual memory. This complies with the manner in which the START MANAGER routine of the Macintosh OS (operating system) establishes the beginning location of the startup system stack. Numerous alternative approaches can be implemented for mapping and locating a startup system stack, as long as the logical address space which will hold the startup system stack is mapped to a location in physical memory, even though that location may change and may be unknown. The example described above is at present believed to provide good performance. An alternative technique, which would eliminate the requirement to map out a zone for the startup system stack (which is effectively the supervisor stack), is to perform the warm re-boot in user mode. Such an approach involves other complications, but does not require the stack integrity needed for operation in supervisor mode.

Following the re-mapping of step 32, the page map is altered at step 34 to map the virtual memory code to the top of the virtual memory address space. This can fill the space vacated by the memory taken to create a mapped zone for the startup system stack.

Once the page map is altered, certain frequently used pages of the system (and debugger, if any) are locked, or prevented from being swapped out to disk by the virtual memory algorithm described below, by setting an appropriate flag at step 36. It is not necessary in all cases to lock such pages, although such an approach is generally preferable to ensure critical pages are not swapped out to disk, to maintain diagnostic integrity (for debugging, if necessary), to maintain a zone of 1:1 logical to physical memory mapping for alternate bus masters, and to increase performance. The zone of 1:1 logical to physical mapping referred to above is typically on the order of 64K bytes, but could vary substantially.

Following the page locking of step 36, the portions of memory zoned for the system and static memory are assigned slow aging status at step 38. As will be discussed hereinafter, assignment of such status simplifies determination of pages which cannot be swapped out to disk. Next, at step 40, the bus error vector is pointed to the bus error routine, and the Swap MMU Mode routine (FIG. 7) is pointed to the new Swap MMU address. tables set up by steps 30-38 by using a call to the Swap MMU routine.

Finally, after the reconfiguring of step 42, a warm re-boot of the machine is performed at step 44. The warm boot uses the same boot code as the original code in the ROMs of the Macintosh computer, but is tailored to avoid any call which initializes or otherwise affects critical memory locations, such as the size and speed of memory (including MEMTOP) and the start of the static memory zone (BUFPTR), or the state of the PMMU, so that the installed virtual memory code will not be disturbed. The warm reboot allows slot drivers and device drivers to re-install in the virtual address space, rather than just in the physical address space, causing the system to appear as it would if the same amount of physical memory as virtual memory existed. During the course of the warm reboot process, the INIT (step lo) will again be entered.

Since this is a second pass installation, the decision at step 16 is yes, causing the process to branch to step 48. At step 48, the process opens the virtual memory file allocated during the first pass initialization, which prevents the user from throwing the virtual memory file away during normal operation. Then during step 50, the read and write trap calls are redirected to the custom routines described hereinafter.

At step 52, a new exception vector table is created in static memory and marked as protected, or immune from page swaps, and then initialized with all vectors in the table pointing to Re-Vectoring routine. Next, at step 54, the Bus Error, Privilege, Trace and Line 1010 vectors are patched to the routines in the new exception vector table. The Vector Base Register (VBR) is then pointed to the newly created vector table at step 56, and the user stack pointer is set to that stack's current value in step 58. In step 60, the supervisor stack pointer is set to a buffer protected from memory swaps to disk. Finally, at steps 62 and 64, the icon showing the loading of virtual memory is displayed and the processor is switched to user mode from supervisor mode. The system returns at step 66, ready to begin processing of user programs.

Once the code of the present invention has been installed, the logical architecture of memory is substantially as shown in FIG. 2b. The arrangement of FIG. 2b, which can be contrasted with the arrangement of conventional Apple Macintosh memory in FIG. 1b, continues to show the operating system installed in memory beginning at address 0. Above the operating system zone is the application zone, followed by a user stack zone. The user stack zone of FIG. 2b corresponds generally to the stack zone shown in FIG. 1b, since user programs under the present invention are permitted only to modify the user stack zone. Those of ordinary skill in the art will appreciate that some programs for the Apple Macintosh, such as MultiFinder, create a plurality of application zones and user stack zones within what has been referred to here as a single user stack zone and application zone. Above the user stack zone is static memory, but static memory now includes a zone for conventional static memory, together with specific portions of static memory assigned to perform particular virtual memory functions. Those functions include a supervisor stack zone, a vector base table (pointed to by the vector base register, or VBR, history tables, code for the virtual memory process of the present invention, and zones for the SWAP MMU process, translation tables and transient page storage, all as discussed hereinafter. The installation of the supervisor stack zone into static memory permits the supervisor stack zone to always be in a known location. The supervisor stack zone, which is typically a few thousand bytes, for example 8K bytes, but could range to on the order of 32K bytes, located in physical memory, although its logical address is very near to the top of memory. Those skilled in the art will appreciate that logical addresses need not map always to a physical address on a 1:1 basis.

Re-Vectoring Patch

With reference now to FIG. 3, the flow diagram shown therein describes the redirection of the exception vectors not treated specifically hereinafter. Basically the approach taken by the routine shown in FIG. 3 is to receive the exception vector, look up the value of the address currently stored in the original vector table, and jump to the routine at that address. This leaves the stack unaltered from what it would have been if handled directly. Thus, programs can be fooled into not realizing the VBR has changed locations, while still being permitted to alter vector addresses in the original, zero-vector table. The programs can also affect where the exception will be processed, while leaving the supervisor stack protected. Optionally, to improve system performance, interrupts can be re-enabled during the page fault caused by the exception vector, after saving a copy of the registers and the stack pointer on the stack. Saving such additional information will permit handling of secondary page faults, as will be described in greater detail hereinafter.

In FIG. 3, when an exception vector is received, the routine is called up at step 80, and begins by determining at step 82 whether a page fault is currently being processed. If it is, a copy of the registers and the stack pointer is saved on the stack, and a pointer to the current stack address is saved in a static location, all at step 84. This permits interrupts to be re-enabled, which improves the apparent response of the system.

If no page fault was being processed at step 82, or following step 84 if a fault was being processed, the process continues at step 86 by obtaining the exception vector number from the exception stack frame. The current address pointed to by the exception vector number is then pushed on the stack in step 88, which permits execution to resume in step 90 at the original exception vector address. In this manner, the exception vectors set forth in Table above can be processed in essentially the same manner as for a non-virtual memory system.

Privilege Violation Vector

With reference now to FIG. 4, a solution is shown for another type of problem with occur with a virtual memory system on the Macintosh system. Since the processor is now normally running the operating system and programs in user mode, while the operating system and programs expect to be running in supervisor mode, there will be some occasions in which the CPU will be instructed to execute supervisor-only, or "privileged" instructions. This causes a privilege violation, which typically can be handled in either of two ways. First, the instruction can be emulated in software so that the user program does not know the instruction was not actually executed. The second alternative is to permit the instruction to execute in supervisor mode only under careful supervision, and to then switch the system back to user mode. A combination of these approaches is shown in FIG. 4, in which instructions predefined as "common" be emulated, but other instructions are executed under careful supervision, typically through use of the TRACE instruction in the Macintosh operating system although other techniques are possible.

Thus, when the privilege error occurs, the privilege patch routine is called at step 100. If the privilege error results from a system call by specially authorized code segments, including code of the present invention, the process branches at step 102 to permit a return to the system at step 104, with the system continuing in supervisor mode.

However, if the call is not from the privileged virtual memory code of the present invention, an inquiry is then made at step 106 to determine whether the call causing the privilege error is a "common" instruction. Common instructions, which are herein intended to mean those which are frequently used and easily emulated, are then emulated in software at step 108, and the system returns from the privilege exception at step 109. Typical instructions which may be viewed as common are the move status register to A7 instruction (and its converse), and the change priority instruction. Other instructions, such as the stop instruction, any instruction which accesses or changes the address of the VBR, and the reset instruction are also defined as "common" even though they are infrequent, cannot readily be traced, or must provide different response in the emulated environment. For example, emulation of the stop instruction involves executing a very tight loop to give the appearance of a system halt, and cannot readily be performed under the supervision of the TRACE mode.

In the event the call which led to the privilege violation is not a "common" instruction, the process branches to step 110, where memory-reference accesses are generated in a buffer zone around the user stack pointer. The creation of such a buffer zone ensures that the memory around the user stack pointer is not currently paged out by causing a page fault if the zone is swapped out. If such a page fault occurs, the page will be reloaded, so that as long as the stack pointer points to any location in the buffer zone, the corresponding page should be resident.

Following step 110, a dummy privilege exception frame is created on the user stack at step 112, followed further at step 114 by setting the exception frame status register value to trap after each instruction. Such trapping may also be referred to as "trace", and may be thought of as step-by-step supervision of the execution. Next, at step 116, the exception frame status register value is set for supervisor status. This is followed by saving, at step 118, the current location of the supervisor stack pointer in a static location and setting the supervisor stack pointer to the user stack pointer address at step 120. Finally, a flat is set at step 122 so that the trace exception routine knows to expect a trace exception from the instruction emulator. The process thus permits certain privileged instructions to execute in supervisor mode while at the same time protecting the pointers necessary for virtual memory. Once the instruction completes processing, the routine returns from the exception at step 109.

Trace Patch

As discussed above, in the preferred embodiment of the present invention, use of the TRACE instruction is helpful to emulate certain types of instructions which create a privilege violation. Other instruction emulation techniques could readily be used. In this preferred approach, however, it is necessary to trace, or supervise on a step-by-step basis, the execution of some of the system calls to avoid corruption of the stack. The trace patch, shown in FIG. 5, will permit such supervision, and used to allow execution of calls that cannot be easily emulated, or are not yet known to exist. In such event, the trace patch is called at step 130, and begins at step 132 by inquiring whether the trace was expected from an instruction emulation. If so, the process branches to step 134 so the processor mode will be reset to user mode upon return from this exception. Following the reset, the routine determines at step 136 whether the user program has independently updated the status register. If not, the trace bit is reset at step 138, and the routine returns from the exception at step 140. The routine then returns from the trace exception, again at step 140. Thus, the instruction is allowed to execute in supervisor mode under scrutiny, the trace routine is then switched back out of supervisor mode, and the processor is allowed to continue with other instructions in user mode.

However, if no trace was expected at step 132 from the instruction emulation, the routine branches to step 142, where the routine inquires whether the system is in supervisor mode. If so, the routine jumps to the original trace vector at step 144. If not, the routine branches to step 146, where the trace exception frame is copied from the supervisor stack to the user stack. The supervisor stack exception frame is then changed in step 148 to the return address of the original trace vector, followed in step 150 by clearing the supervisor and trace mode bits from the supervisor stack exception frame. Once this is complete, the routine returns from the exception to the original trace vector at step 152.

Line 1010 Vector Patch

Many operating systems for 68XXX-based machines, such as the Macintosh, use line 1010 traps, or "A" traps, to handle system calls. Generally, the application desiring to execute such a system call will set up either registers or the stack with the calling parameters, and then execute an instruction beginning "1010". The 1010 instruction in turn causes an exception to be generated to the "un-implemented instruction" exception vector, which effectively extends the instruction set of the processor by causing the operating system to evaluate the instruction and generate the desired effects in software. However, such exceptions cause a transition from user mode to supervisor mode, even though the user programs which made the call are operating in user mode with the user stack rather than the supervisor stack. Thus, when such a call is made, it is necessary to substitute the appropriate stack pointer to ensure that the pointer used by the system call is the same stack to which the parameters were originally passed.

This is accomplished by the routine described in FIG. 6, where the line 1010 vector patch is called at step 160. The routine begins by inquiring, at step 162, whether the system was in supervisor mode when the trap was called. If so, the routine jumps at step 164 to the original line 1010 vector address, taken from the original zero-base vector table.

If not, however, the routine branches to step 166, and copies the stack exception frame from the supervisor stack to the user stack. Next, at step 168, the return address of the current exception frame is replaced with the original line 1010 vector address, so that when the return from the exception is made, execution will continue with the appropriate information supplied to the appropriate stack at step 170.

Swap MMU Patch

Under the current Macintosh operating system, there are two common modes of addressing. In twenty-four bit mode, only the least significant 24 bits are ordinarily recognized. However, in some cases with the current operating system all 32 bits are used; presumably this trend will continue with future releases of the operating system, such that eventually all 32 bits will normally be used. When all 32 bits are used, it is necessary to alert the PMMU to fully decode the address, but to still point to the page translation tables set up by the virtual memory routines of the present invention. It is also necessary to be able to transfer back to 24 bit mode. This toggling can be accomplished by the routine shown in FIG. 7, which begins at step 180 by a call to the Set MMU Mode routine. The routine begins at step 182 by determining whether the system is already in the requested mode. If it is, the routine returns at step 184. However, if not, the routine inquires at step 186 whether 32-bit mode has been requested. If it has, the PMMU (shown in FIG. 1c) is set at step 188 to decode all 32 bits, but still uses the page translation tables to decode the physical address for any location in the virtual address space. A flag is then set at step 190 to indicate the current state is 32 bit mode, and the routine returns at step 192.

On the other hand, if the inquiry at step 186 determines 32-bit mode is not requested, the PMMU is set at step 194 to ignore the top byte, or top 8 bits, of the 32-bit address, and the corresponding flag is set at step 196. Again, the routine returns at step 192.

Bus Error Vector

When a memory location is called for, but is not immediately available for referencing, a bus error is generated. In such an instance, it is necessary to determine whether the location is unavailable because it has been paged out to disk; this can be accomplished by the routine shown in FIG. 8. The bus error vector is called at step 200, and begins at step 202 by saving the state of the registers and the PMMU, followed by determining the address and the cause of the bus error at step 204.

If, as determined at step 206, the bus error is not due to a page fault, the registers and PMMU setting are restored at step 208, and the routine jumps to the original bus error address vector at step 210. However, where the inquiry at step 206 determines that a page fault has occurred, the routine inquires at step 212 whether a page fault was already being corrected that is, the process of swapping information in from disk was already in progress) when this page fault occurred. If it was, it will simplify operations to finish correcting the first page fault before dealing with the second. This is accomplished in step 214 by saving, at a different location, a copy of the stack from where the new page fault occurred to the current stack pointer. Next, at step 216, the registers are restored to their state prior to the occurrence of the second page fault--that is, their status during the handling of the first page fault, which was saved at step 82 shown in FIG. 3. Then, at step 218, set the return address of the original page fault to resume execution at the double fault restoration routine shown in FIG. 9. The routine then preferably switches to a very high level of priority, so it will not again be interrupted by the process which caused the second page fault, and returns at step 220 to finish handling the first page fault.

If, as should usually be the case, there was no prior page fault being handled when the inquiry was made at step 212, the routine continues by selecting at step 222 a page not likely to be needed soon. While various algorithms exist for making this selection, one acceptable algorithm is shown in FIG. 10, which uses page usage history or aging tables. That page is then mapped out as non-resident, still at step 222. At step 224, a determination is made as to whether the page has been modified since the last time it was written out to disk. If it has, the page is written to disk at step 226, and a flag is set that the page now has a disk image.

An inquiry is made at step 228 as to whether the faulted page has a disk image. If it does, the disk image of the faulted page is read from disk at step 230 into the physical memory of the selected page, while the faulted page is temporarily mapped to an alternate location, which may be regarded as a transient page zone (FIG. 2b), and the page modified flag is cleared. The transient holding zone is used to prevent processing of incorrect code or data in the event an interrupt occurs which requires the use of code or data on the page before the code or data in that page can be fully updated from its disk image. If the answer to the inquiry at step 228 was no, or following the reading of the disk image in step 230, the routine advances to step 232 and remaps the now-restored faulted page to the address where the page fault was detected. Thereafter, in step 234, the registers and PMMU status are restored, and the routine returns in step 236.

If the inquiry at step 212 did not find a second page fault, the return at step 236 will simply return to the system. However, if a second page fault did exist, the return address supplied at step 236 will jump to the routine shown in FIG. 9 for double faults, so that the secondary fault(s) can now be handled. The routine is called at step 240, and begins at step 242 by copying the saved stack (caused by the second page fault) back to its original location. The registers are then restored in step 244 to their state at the time of the second page fault. Next, the return address for the stack is altered in step 246 to return to the routine to restore the registers and stack to the state they were in when the second page fault occurred. The system then resumes processing. If the page swap which solved the first page fault also solves the second page fault, no error will be reported. However, if the solution to the first fault does not solve the second page fault, the second page fault will recur. However, upon recurrence, it will be the first fault, and can be handled accordingly. The routine then returns at step 248 from the bus error exception.

Page Selection Routine

For any virtual memory system to work, it is sometimes necessary to retrieve pages of memory from disk. If physical RAM is full, as it presumably is, it is necessary to mark to disk, or page out, pages in physical memory to make room for the pages retrieved from disk. Various criteria can be implemented which will accomplish this task with reasonable results.

However, at the same time, certain critical pages should not be swapped out to disk. This set of critical pages includes, particularly, the pages of memory necessary to execute a page swap. While these pages can, in some virtual memory processes, be readily identified, such identification may not be done so readily in the Apple Macintosh environment where the code which implements virtual memory is added to an existing operating system. Of course, with sufficient knowledge of both the operating system and the process of the present invention, it would be possible to identify, in advance, such critical pages and mark them as immune to page swaps.

The routine shown in FIG. 10 has been optimized for aftermarket use in the Apple Macintosh environment, in part because it does not need advance identification of the critical pages. More specifically, the page selection routine of FIG. 10 relies primarily on three factors: a history table (which is based on usage in the preferred embodiment but may be based on any of a wide variety of criteria), a "don't swap this page" flag, and a page modified flag.

The history table (see FIG. 2b) concept tracks, for example, how recently and frequently a page has been accessed. The "don't swap"flag, discussed further below, protects certain key pages of physical RAM from ever being swapped to disk, and is designed to protect critical information such as the virtual memory code, and some sections of the device manager, disk driver, system traps, and trap patches. The page modified flag determines whether a page has been modified since retrieved from disk.

One reason for determining whether a page has been modified since retrieved from disk relates to the reasons for allocating, in the preferred embodiment, a disk file which is larger than the total amount of memory required to supplement the existing physical memory to the total amount of virtual memory. Thus, for example, for a current Macintosh II which is capable of addressing a maximum of eight megabytes under the current release of the Macintosh operating system, the disk file may also eight megabytes, although either larger or somewhat smaller sizes would also work. This, effectively, permits a disk image of each page to be maintained in physical memory (RAM). It will be apparent to those skilled in the art, given the foregoing discussion and the fact that a disk image can always be maintained for unmodified pages in physical memory, that, where possible, an unmodified page might generally be selected for swapping out, since this eliminates the need for a disk write and correspondingly increases performance. By weighing these factors, as discussed below in connection with FIG. 10, a reasonably optimized candidate for replacement is identified.

In general, the page selection routine shown in FIG. 10 is a "winnowing out" process by which the system itself determines, on a long term iterative basis, what the critical page set is likely to be, and errs generally on the side of including non-critical pages to avoid swapping out critical pages. The first basic assumption is that all pages critical to performing a page swap are used during each complete page swap, where a complete page swap includes both a read and a write. By basing selection of a page to be swapped out initially on page usage history, and not swapping out any page used during each complete swap, all the critical pages (plus some additional, non-critical pages) will be, at least preliminarily, protected from being swapped out.

At this point a potential problem exists. Depending on the size of physical memory, it is possible that the entirety of physical memory will consist of pages that are used during the period of time between each page swap, even though some of those pages are non-critical. This necessitates a second level criteria for deciding which pages are non-critical. While many such criteria will work, a presently preferred approach involves setting a flag bit for each page written in memory during the initial installation of the virtual memory software. This marks all critical pages, but also marks many non-critical pages. It will be apparent to those skilled in the art that the truly critical pages have both a heavy usage history (i.e., satisfy the first criteria), and also have the flag bit set (the second criteria).

The combination of the two criteria then permits selection of a non-critical page for swapping. By using the page usage history criteria to make a determination of which page to swap out so long as not every page is heavily used, non-critical pages including those pages with the flag bit set can be swapped out to disk. Then, in the somewhat unlikely event that every page in memory has a heavy usage history, those pages which do not have a flag bit set can still be selected as non-critical. In this manner, a non-critical page can always be selected to be swapped out to disk.

The page selection routine described generally above can be appreciated in greater detail from the following. The page selection routine is called at step 300, and begins at step 302 by inquiring whether it is time to update the aging tables. The criterion for updating the aging tables can be varied over a fairly wide range, and might include real time, recent usage history of any one or more pages, frequency of occurrence of page faults, or number of page swaps since last update, as just some examples. Time and usage history have thus far been used in a preferred approach. If the inquiry at step 302 determines that it is not time to update, the modified and unmodified pagse with the lowest usage history are identified at step 304.

However, if an update is in order, the time out flag is reset at step 306. The aqing tables are then updated at step 308 with usage information since the last update, and the usage flag is reset. Next, the modified and unmodified pages with the lowest usage history (as stored in the aging tables) are identified at step 310.

Regardless whether the aging tables were updated, the appropriate branch supplies the usage history of the modified and unmodified pages to step 312, where the usage history of the unmodified page is compared to that of the modified page in accordance with any suitable weighting criteria, and the least used page as determined by that criteria is then selected at either step 314 or step 316, and passed to the next step. As noted above, it is faster to mark an unmodified page as non-resident, and so in most cases it is preferable to use a weighting criteria that tends to select unmodified pages to be made non-resident.

In some cases, however, it will not be desirable to swap out the selected page, whether modified or unmodified. Most such pages are marked with a "don't swap" flag. However, it might occur that a page that is not so marked will still be selected by the page selection routine because all pages are being used regularly. Such undesirable swap-outs can be avoided by keeping track of usage history, such as by the aging table discussed above, and imposing a rule that any page which has always been used during the period between any two disk swaps is not to be swapped out. This is shown at step 318, and if the selected, least used page does not have a full usage history, it is selected to be marked non-resident (swapped out) at step 320.

Alternatively, if the page selected as least used does have a full usage history, that page cannot be selected, and the aging tables are again updated at step 322 so that another page can be selected. Pages having a full usage history but which are not marked with a "don't swap" flag may be marked as slow aging pages. Then, as shown at step 324, the aging tables for the fast aging pages can be updated, new "lowest usage" unmodified and modified pages selected, and the routine returned to step 312 for further processing.

Read Patch

The read patch routine, shown in FIGS. 11a-11b, is essentially a pre-fetch of pages of disk data to physical memory. Such a pre-fetch is particularly helpful in the virtual memory context to avoid a page fault during time critical operations in which occurrence of a page fault during the operation can cause an error. An example of such a time critical operation is a read (or write) from disk in which a page fault during the read can cause the status of the disk interface to be lost. More specifically, during a disk reads or writes, the spinning hard disk may not be able to wait and hold its place while a page fault is made good. Thus, it is helpful to avoid such situations by what is referred to herein as "pre-fetching".

Successful use of pre-fetching relies in part on the good programming practice that I/O operations are executed only through the operating system. That is, any program or peripheral that needs to perform an I/O operation posts that request to the operating system. The request to the operating system includes where the information is to be placed in memory, how much information is to be transferred, and where the information can be found. The operating system then performs the operation and returns the result. By intercepting and managing such calls, it is possible to ensure that no page faults will be generated from the I/O request during the critical I/O period.

The solution to this problem used in a preferred embodiment of the present invention amounts to keeping a list of the pending I/O operations, and the locations to which those I/O operations have been directed. Those locations are temporarily marked with a "Don't Swap" flag, and so can be regarded as temporarily locked in physical memory, or RAM. When the I/O operation has been completed, the "Don't Swap" flag is removed for those temporarily locked locations, and they are again free to be swapped if appropriate.

In rare instances, it is possible that an I/O operation will request a single transfer which is larger than the number of available pages of physical memory. For example, a Macintosh computer having only one megabyte of RAM available for such an I/O call may receive a request for a five megabyte transfer. There is not enough memory available to handle the operation in one step. In such event, the process of the present invention can break the large read request into a number of smaller read operations, each of which can be accommodated by the amount of available memory. Thus, for the example of a request for a five megabyte read, the present invention can readjust the I/O call into five one megabyte reads. Following the last small read, the call is readjusted back to appear as if a single five megabyte read occurred, so that the calling program is unaware that the read was not performed as one contiguous piece.

To understand the foregoing in greater detail, reference is again made to FIGS. 11a and 11b. The read patch is entered at step 340, and inquires at step 342 whether the call which entered the read patch is a file system call rather than an I/O call. If it is a file system call, the routine branches to step 344, where it jumps to the original read trap address.

However, if the call which caused entry to the read patch is an I/O call, the routine branches from step 342 to step 346, where supervisor mode is enabled. The system starts with the first block of information to be read from disk, at step 348, and determines at step 350 to what memory page the block will be written. It is then determined, at step 352, whether that page is resident. If not, a determination is made at step 354 whether the page of physical memory will be completely overwritten by the read from disk. If the page is to be overwritten, the disk image flag for the page is cleared at step 356; if not, step 356 is bypassed. Either way, the page fault routine of FIG. 8, beginning at step 222 is then used to validate the page.

If the page was not previously marked with a Don't Swap" flag, the page is then temporarily locked at step 360 by setting its "Don't Swap" flag, and the page is added to a list of temporarily locked pages. Once the page has been temporarily locked, a determination is made at step 362 as to whether additional blocks of data are to be read in. If they are not, the routine branches to step 364 where the requested read is performed, following by unlocking the temporarily locked pages at step 366, restoring the status register from the stack at step 368, and finally returning at step 370.

In many such cases, however, additional blocks of data will be called for, in which case the routine will branch from step 362 to step 372. At step 372, a determination is made whether the maximum number of temporarily lockable pages have already been locked. In most cases, the answer will be no, and the routine will loop by examining the next block to be read from disk at step 374 and then re-entering the routine at step 35o.

In some oases, however, the maximum number of pages will have been locked, as determined at step 372. In such event, it is necessary to break the read into a plurality of smaller reads. To accomplish this, the routine will branch to step 376, where the size of the original read request will be stored. Then, at step 378, the read request is reduced to match the maximum number of allowable locked pages, followed at step by a read of that reduced size.

After completion of the reduced read, another read is set up at step 382, extending from the end of the last block actually read to the end of the originally requested read. Following set up, the next block of information is read from disk at step 384 and, as before, the page to which that block is to be written is identified. If the page is resident, as determined at step 388, the page is added to a second list of temporarily locked pages.

As before, if the page is not resident, an inquiry is made at step 392 whether the page of physical memory will be completely overwritten by the read from disk. If the page is to be completely overwritten, the disk image flag for the page is cleared at step 394. If the page is not to be overwritten, or after clearing the disk image flag if to be overwritten, the routine continues with step 396, where the page fault routine shown beginning at step 222 of FIG. 8 is used to validate the page.

Thereafter, the successive next-last in the list of temporarily locked pages is selected at step 398, and that page is swapped out at step 400. This frees up a page for this block of the read operation (previously no additional pages of physical memory were available since we had reached the maximum number of locked pages in performing the previous section of this I/O call), and so this logical page is then remapped into RAM at step 402 to be ready for the next read, at which time it will overwritten.

The results of either step 390 or step 402 then cause the routine to continue at step 404, where an inquiry is made as to whether there are more blocks to be read in this request. In some cases there will be more blocks to read, in which case the routine will branch to step 406, where a second inquiry is made as to whether the maximum number of temporarily lockable pages has already been locked. In a good percentage of cases the answer will be no, in which case the routine will loop back to step 386 through step 408, where the next block to be read from disk is examined. In some cases, however, the maximum number of temporarily locked pages again will have been met, so that a reduced size read is again required at step 410. In this case, the size of the read is reduced to the amount of validated memory, and then a read is performed at step 412, after which the routine loops back to step 382.

Eventually, the looping will return to step 404, and no more blocks will be requested. At this point, the routine branches to perform the final read, at step 414, followed by unlocking the pages of the second list of temporarily locked pages at step 416. Next, the parameter block pointed to by the original read request is restored to the same state as if it had been completed in one pass, at step 418, and the status register is restored from the stack in step 420. The routine then returns control to the system at step 422. It can be appreciated that, in this manner, large size reads can be accomplished. Although not shown, in a similar fashion a write patch routine may be implemented which breaks write operations from the virtual memory space to a conventional disk file into small enough operations to be processed with the amount of available physical memory. The WRITE PATCH is essentially identical to the READ PATCH, except that steps 354, 356, 392 and 394 may be deleted. A similar technique can be used for any critical operation which cannot tolerate the occurrence of a page fault during the operation.

Attached hereto as Appendix A is a printout, in object code form, of the code necessary to implement the present invention on an Apple Macintosh II operating under the current version (6.0.2) of the Macintosh operating system.

From the foregoing teachings, it can be appreciated by those skilled in the art that a new, novel and unobvious virtual memory system for use on Apple Macintosh personal computers using the 680X0 microprocessors with appropriate memory management has been disclosed. It is to be understood that numerous alternatives and equivalents will be apparent to those of ordinary skill in the art, given the teachings herein, such that the present invention is not to be limited by the foregoing description but only by the appended claims.

Claims

I claim:

1. A method of utilizing physical memory and peripheral storage in an Apple MacIntosh computer running under an Apple Macintosh operating system, wherein the Apple Macintosh computer includes a suitable microprocessor capable of coacting with memory management logic either internal or external to the microprocessor, and an amount of physical memory, and wherien the Apple Macintosh computer is capable of operating in both user and supervisor modes, as virtual memory comprising the steps of: allocating a portion of the peripheral storage as a virtual memory file, determining the amount of the physical memory resident in the Apple Macintosh computer, setting the memory management logic to address at least part of the physical memory and at least part of the virtual memory file as virtual memory space, whereby there is a first portion of the virtual memory space in the physical memory and a second portion of the virtual memory space in the peripheral storage, establishing a supervisor stack in the physical memory, reconfiguring the Apple Macintosh computer to continue processing, normally performed in supervisor mode, in the user mode, including establishing at least one user stack in the virtual memory space in response to an attempt by the Apple Macintosh operating system to establish a stack and forcing the Apple Macintosh operating system or at least one currently executing application program to use the at least one user stack instead of the supervisor stack as if the Apple Macintosh operating system or the at least one currently executing application program was still operating in the normal supervisor mode by redirecting the microprocessor to use the at least one user stack when the Apple Macintosh operating system or the at least one currently executing application program attempts to address any stack during processing normally performed in supervisor mode, and swapping between the first and second portions of the virtual memory space, in accordance with a predetermined criteria, non-critical information.

2. The method of claim 1 further including the step of retaining critical information in the first portion of the virtual memory space.

3. The method of claim 2 wherein critical information includes at least the location of the supervisor stack.

4. The method of claim 3 further including the steps of switching to supervisor mode to perform the information swapping step.

5. The method of claim 1 further including the step of organizing the virtual memory space into pages, and wherein the predetermined criteria includes consideration of page usage history.

6. The method of claim 2 further including the step of causing the macintosh operating system to recognize the entire virtual memory space as available physical memory by rebotting the Apple Macintosh computer, after allocating the virtual memory file and setting the memory management logic, without resetting the memory management logic or critical memory configuration values.

7. The invention of claim 1 further including the step of retaining the supervisor stack in a known location in the physical memory.

8. The invention of claim 6 wherein oen of the critical memory configuration values is the value of MEMTOP.

9. The invention of claim 6 wherein one of the critical memory configuration values is the initial value of BUFPTR.

10. A method of installing virtual memory comprising a combination of physical memory and peripheral storage in an Apple Macintosh computer capable of operating in privileged and protected modes running under an Apple Macintosh operating system wherein the Apple Macintosh computer includes a suitable microprocessor capable of coacting with memory management logic either internal or external to the microprocessor, and an amount of physical memory, comprising the steps of: allocating a portion of the peripheral storage as a block, setting the memory management logic to address at least a portion of the physical memry and at least a portion of the block of the peripheral storage as virtual memory space, reconfiguring the Macintosh operating system without further resetting the memory management logic to cause the Macintosh operating system to recognize the virtual memory space as available physical memory nd to cause the Apple Macintosh computer to continue processing, normally performed in priviledged mode, in the protected mode, including establishing at least one user stack in the virtual memory space in response to an attempt by the Macintosh operating system to establish a stack and forcing the Macintosh operating system or at least one currently executing application program to use the at least one user stack as if the macintosh operating system or the at least one currently executing application program was still operating in normal privileged mode by redirecting the microprocessor to use the at least one user stack when the Macintosh operating system or the at least one currently executing application program attempts to address any stack during processing normally performed in privileged mode.

11. A method of utilizign physical memory and peripheral storage in a computer system running uner an operating system, wherein the computer system includes a suitable microprocessor capable of coacting with memory management logic either internal or external to the microprocessor, and an amount of physical memory, and wherein the computer system is capable of operating in both user and supervisor modes, as virtual memory comprising the steps of: allocating a portion of the peripheral storage as a virtual memory file, determining the amount of the physical memory resident in the computer system, setting the memory management logic to address at least part of the physical memory and at least part of the virtual memory file as virtual memory space, whereby there is a first portion of the virtual memory space in the physical memory and a second portion of the virtual memory space in the peripheral storage, establishing a supervisor stack in the physical memory, reconfiguring the computer system to continue processing, normally performed in supervisor mode, in the user mode, including establishing at least one user stack in the virtual memory space in response to an attempt by the operating system to establish a stack and forcing the operating system or at least one currently executing application program to use the at least one user stack instead of the supervisor stack as if the operating system or the at least one currently executing application program was still operating in the normal supervisor mode by redirecting the microprocessor to use the at least one user stack when the operating system or the at least one currently executing application program attempts to address any stack during processing normally performed in supervisor mode, and swapping between the first and second portions of the virtual memory space, in accordance with a predetermined criteria, non-critical information.

Patent Citations (12)

Patent	Date	Inventor
US3815103	1974-06-01	Holtey et al.
US4493035	1985-01-01	MacGregor et al.
US4519032	1985-05-01	Mendell
US4528624	1985-07-01	Kamionka et al.
US4542458	1985-09-01	Kitajima et al.
US4592011	1986-05-01	Mantellina et al.
US4617624	1986-10-01	Goodman
US4669043	1987-05-01	Kaplinsky
US4714993	1987-12-01	Livingston et al.
US4825358	1989-04-01	Letwin
US4849878	1989-07-01	Roy
US4868738	1989-09-01	Kish et al.

Non-Patent Literature (15)

"Editorial--'89 Won't be Apple's Year of Multitasking", MacWeek, Jan. 3, 1989 p. 22.
"Virtual Memory Ends RAM Jam", MacWeek, Jan. 10, 1989 p. 1.
"Latest--Virtual Memory Draws Nearer", MacWeek, Jan. 31, 1989 p. 1.
"First Look--Virtual 2.0 Beats Mac's 8M-Byte RAM Barrier", PC Week, Oct. 23, 1989, pp. 15, 18.
Designing Cards and Drivers for Macintosh II and Macintosh SE Apple Computer, Inc., Addison-Wesley Publishing Company, Inc. 1987; ISBN 0-201-19256-X (pp. 1-4 to 1-6).
Macintosh Family Hardware Reference Apple Computer, Inc., Addison-Wesley Publishing Company, Inc., 1988; ISBN 0-201-19255-1 (pp. 16-10 and 16-11).
MC68020 32-Bit Microprocessor User's Manual (Third Edition), Motorola, Inc., Prentice-Hall, Inc. 1984, 1985; ISBN 0-13-566951-0 (particularly Section 1.3).
"Eternal Ramdisk Program", Dec. 06, 1986, CompuServe Information Service.
Byte, Nov. 1989, pp. 341-360.
"Connectix's Virtual Memory Solution", Macintosh News, Jun. 5, 1989, p. 8.
"Mac the Knite"-"No field test for 3-slot '030box2", MacWeek, Nov. 29, 1988, p. 70.
MC68030 Enhanced 32-Bit Microprocessor User's Manual (Second Ed.) Motorola, Inc., Prentice-Hall, Inc., 1989, ISBN 0-13-566951-0 (pp. 1-1 to 1-12).
MC68851 Paged Memory Management Unit User's Manual; Motorola, Inc., Prentice-Hall, Inc. 1986 ISBN 0-13-566902-2 (particularly Chap. 2 and Appendix C).
MC68851 Paged Memory Management Unit User's Manual, Second Ed.; Motorola, Inc., Prentice-Hall, Inc., 1989, ISBN 0-13-566993-6 (as with the first edition, particularly Chap. 2 and Appendix C).
Operating Systems Design and Implementation, Andrew S. Tanenbaum, Prentice-Hall, Inc., 1987; ISBN 0-13-637406-9 (Chap. 4).

Abstract

Description