Xref: utzoo comp.sys.mac:32406 comp.sys.mac.programmer:6558 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!uunet!intercon!amanda@intercon.UUCP From: amanda@intercon.UUCP (Amanda Walker) Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: Re: Re: System 7.0 Message-ID: <23-May-89.112745@192.41.214.2> Date: 23 May 89 15:18:00 GMT References: <18660@cup.portal.com> <3353@tank.uchicago.edu> Sender: news@intercon.UUCP Reply-To: amanda@intercon.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Sterling, VA Lines: 51 In article <18660@cup.portal.com>, Greg_Mark_Finnegan@cup.portal.com writes: > Jonathan Garber's quote ("...there's only one way to do virtual memory...") > bothers me a bit. The Connectix VM scheme limits you to 8Meg period. Apple's > method lets you go to 14Meg by mucking with NuBus (in 24 bit mode) and gobs > more in 32 bit mode. > > Sounds like 2 ways to do virtual memory to me (and probably a judge). First of all, the approaches will be similar in many respects simply because they both use the same hardware, i.e., a Motorola PMMU in a Macintosh. That's not what's patentable. From everything I've seen on both of these schemes (which isn't any more than most of the rest of the group :-)), there seem to be some major differences in how they are implemented. I think these differences are simply the result of Connectix being a third-party developer, and Apple being, well, Apple... From the descriptions that have appeared here and in the trade rags, Virtual is a marvelously clever piece of software, but it looks like the authors have attempted to do as little messing about as possible with the lower levels of the system, which means that the pager sits (more or less) between the application and the toolbox. Since they are using the standard SCSI manager, they can't handle page faults during I/O operations. They get around this by preflighting disk accesses in order to insure that all of the buffers are paged in before the operation starts. This does in fact seem to work, although it causes problems for scanners and other devices that talk to the SCSI manager directly instead of via the file manager. I'll call this method "second guessing the applications," and I suspect that this is what the patent application covers. Apple seems to be taking another approach, namely rewriting the SCSI manager to be reentrant, so that page faults can be serviced even when other SCSI operations are pending. This localizes most of the patching to one area, but it's something I think only Apple can do effectively, since they are in control of what the standard system software consists of, and I don't see how it would infringe on Virtual's stuff, since it removes the need for most of the cleverness involved in using the current SCSI manager. Both schemes involve tradeoffs: Virtual involves lots of little patches all over the I/O system, while Apple's VM involves completely replacing one OS manager and leaving the rest of the I/O system more or less alone. Apple's scheme involves a fair amount of cleverness, too, with the idea of remapping the NuBus to make room for more memory in a 24-bit addressed system. Once you see it, it seems obvious, but I still think it was pretty ingenious on the part of whoever thought it up in the first place. -- Amanda Walker InterCon Systems Corporation