On Tue, 8 Jan 2002, Gavan Fantom wrote:

: > You then lose things such as mmap() and fork()[!!] and have to do some more
: > "interesting" things to implement vfork() and proper shared text pages.
:
: You lose an efficient mmap(), certainly. I don't see why you need to lose
: fork(). Not having an MMU doesn't prevent making a copy of memory, it just
: means you can't use COW to do it. And, let's face it, fork() has been
: around much longer than virtual memory.

fork() in its *current* incarnation (and interpretation) relies on virtual
memory.  Prior to 32V, it used the memory "banking" facilities of the
PDP-11.  "Banking" was simply a very old type of memory management that was
very similar to how virtual page translation happens today.

When you fork(), you have to have a complete copy of all of the .data
segment and heap/brk of a program that is *not* shared between processes.
For a quickie illustration, let me do:

    pid_t *foo = malloc(sizeof pid_t);

    *foo = fork();

In a modern interpretation of fork() semantics, you'd expect *foo to be the
pid of the child in the parent process, and 0 in the child process.  But
without completely changing the concept of a C pointer, you cannot sanely[*]
guarantee this without a MMU.  After all, the address contained in "foo"
does not change in either the parent or the child before the assignment!

[*] The only alternatives are to change the C compiler's notion of a pointer
    (not easy, to be sure), or to copy memory around every time a process
    context switches.

: Proper shared text pages aren't going to happen.

Actually, shared text pages are relatively easy in a MMU-less world, given
all code being PIC.  (Think "data base offset register".)  Shared *data*
pages don't happen.

: > This is mainly in the output of final binaries and their handling by the
: > kernel and dynamic loader.  In short, all binaries end up needing handling
: > as if they were shared objects.
:
: Isn't that just a case of twiddling a few knobs?

Not quite.  Not all platforms' interpretation of "PIC code" is adaptable
directly to a non-protected memory system.  There's important subtleties
here that are a bit lengthy to discuss right now.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/