Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!att!cbnewsk!ech From: ech@cbnewsk.ATT.COM (ned.horvath) Newsgroups: comp.sys.mac Subject: Re: PMMU... Message-ID: <1083@cbnewsk.ATT.COM> Date: 27 Sep 89 21:21:28 GMT References: <35041@apple.Apple.COM> Distribution: usa Organization: AT&T Bell Laboratories Lines: 83 This is getting silly. What follows is Virtual Memory 101; for a GOOD treatment, go get a book -- NOT from a major hardware vendor! -- on operating systems, or dig out the ancient article on Virtual Memory, by P.J.Denning, in Computing Surveys, early '70s. Read it, understand it, THEN post here. An MMU is a "Memory Mapping Unit," and it does precisely that: addresses generated by the processor go to the MMU, which may: 1 translate them to physical addresses to be passed to the physical RAM; 2 raise an exception because the address is unmapped; or 3 raise a protection violation exception; or 4 pass the address through to physical RAM unchanged. The HMMU (third generation Fake MMU -- get it?) which is standard in the Mac II just does 4. It is basically a NO-OP with the same pin-outs as a 68851. The on-chip MMU in the 68030 is capable of all four. The 68851, aka PMMU, replaces the HMMU in a vanilla Mac II. The 68851 supplies a proper superset of the 68030's MMU capabilities, so any OS designer with the sense Ghod gave a door will program to the '030 subset, which will catch the '020 + '851 crowd for free. Now. An MMU is an ENABLING technology. It maps addresses and/or raises non-present memory exceptions. Several wonderful and INDEPENDENT things can be done with that capability: A. Use a different namespace -> physical space map for each process. This provides the process with the illusion of a virtual machine. It also provides some protection: if MacDraw's map doesn't include RAM assigned to the Finder, then stray pointers in MacDraw can't trash the Finder's RAM. Is it perfect? Of course not. Is it better? You damn betcha. Is it the programmer's friend? Well, when I'm debugging a program, it's nice to know that the debugger isn't being creamed by the debuggee -- more about this presently. B. Use a larger namespace than you have physical space, and plan to fetch stuff you need when you need it. This uses the exceptions raised for non-present memory: the exception handler fetches the desired bit of stuff, patches up the map to indicate its presence, and restarts the instruction (which presumably succeeds). This is not unlike what the segment loader does today, except that the segment loader just colludes with your favorite linker to get the job done, without any special hardware assist. C. Manage your RAM more effectively. There's no longer any reason why the System Heap (or any other heap) can't grow/shrink on demand, since it only needs to be LOGICALLY contiguous, not physically contiguous. D. Permit selective access -- e.g. read-only, execute-only -- to various objects. With a bit more work, provide "read-mostly" access -- e.g., you might mark the low-memory globals read-only, but permit (say) BootDrive to be set by the program by INTERPRETING the instruction in the OS. Now, with all these options, different people will opt to implement different uses. No combination is "true virtual memory," and anyone who attacks system 7 on that basis probably has an axe to grind. Option B is what Virtual provides on a global basis, and that is all that Apple have chosen to do for system 7. No protection, no dynamic system heap or user heaps. Those would be very nice to have, and I'm rather surprised to hear Chuq defending the decision to leave them out. But options A and C would require that Finder, Multifinder, and various debuggers (including, but not limited to, SADE) be modified to deal correctly with the new regime. Those problems aren't insurmountable, particularly for the sort of phreaks who write system software (see ptrace(2) in your favorite unix manual). But the sum total is a lot of interdependent changes, and a delay in releasing system 7. I think of system 7 as "halfway to Unix," and I fully expect that system 8 will finish the job. Now, before you netMacMorons(tm) flame me for that expectation, I'll ask you to recognize the basic facts: Unix is pretty on the inside, ugly on the outside. Macintosh has it the other way 'round. When the MacOS becomes Unix on the inside while remaining Mac on the outside -- like what Jobs is trying to do with NeXT, maybe? -- that will be a *GOOD THING*. Getting from here to there is a lot of work, for third parties as well as Apple. =Ned Horvath=