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=