-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mind you, what you can do in the absence of an MMU is highly dependent
on other capabilities of the processor architecture being used.

Motorola 68k processors, for example, have a pretty wide array of
indirect and PC-relative addressing capabilities.  Using the latter, and
a compiler configured to emit pointer references as PC-relative memory
access, a fairly simple-minded fork() (copy the whole damn address
space) is _certainly_ possible.

Depending on code size, the same could be done with Intel x86 processors
as well, using base-relative addressing -- in this case, a simple-minded
fork() would make a copy of the process address space and then update
the base register in the new process.

The former approach, by the way, was implemented in exec(), but not
fork() in MiNT (which ran on atari, mac68k, and mvme68k hardware).
Because this was done at exec() time, MiNT provided vfork() semantics
only, but it is not hard to imagine a similar approach being used to
provide a MiNT fork() implementation.

On Tue, 8 Jan 2002, Todd Vierling wrote:

>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.
>
>

- -- 
				Jim Wise
				jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8O08LN71lEcOYcw4RAtCsAJ9131+e6FAl9EUTP48BPttIyks+ZwCg0yqQ
cyJOGKowweNnYGARzZ3uw3Q=
=gfzh
-----END PGP SIGNATURE-----