Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!sun!amdcad!ames!hc!beta!cmcl2!rutgers!bellcore!faline!ulysses!sfmag!sfsup!shap
From: shap@sfsup.UUCP (J.S.Shapiro)
Newsgroups: comp.sys.mac
Subject: Re: Virtual Memory with the Mac OS
Message-ID: <2218@sfsup.UUCP>
Date: Mon, 19-Oct-87 23:13:45 EDT
Article-I.D.: sfsup.2218
Posted: Mon Oct 19 23:13:45 1987
Date-Received: Wed, 21-Oct-87 07:13:09 EDT
References: <2653@okstate.UUCP> <2542@batcomputer.tn.cornell.edu> <2929@husc6.UUCP>
Organization: AT&T-IS, Summit N.J. USA
Lines: 28
Summary: Is the 65881 init code already there?

In article <2929@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes:
> 
> The wait states are already there.  Two of 'em.  The 851 doesn't add any more.
> As I understand it, it's a drop-in replacement for the fake MMU that's in
> there now.
> 
> I don't think that interrupt handler is so simple.

A somewhat more interesting question is whether or not if you wanted to
experiment with this chip there is sufficient code out there in the current
System version to at least initialize the page maps right for *normal*
operation (i.e. no paging, just act like the existing fake). As to the
interrupt driver, I see no reason whatsoever to believe that the interrupt
driver is terribly hard. Paging algorithms are well understood, and a
number of adequate ones are publicly available (see, for example, Doug
Comer's book on XINU). Putting together a buffer cache and setting up a
paging area is straightforward. Getting paging to work correclty directly
from the application binary file, on the other hand, might require some
very delicate manipulation and the use of some bit to mark the binaries
busy (consider, for example, the problem of someone compacting your disk
while you are paging from one of the applications, which is possible under
multifinder.

This raises an interesting question. If I attempt some clever disk
compaction scheme while a file is open, what happens?

Jon Shapiro
AT&T