Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!uplherc!esunix!bambam!bpendlet
From: bpendlet@bambam.UUCP (Bob Pendleton)
Newsgroups: comp.arch
Subject: Re: IBM PC prehistory
Message-ID: <380@bambam.UUCP>
Date: 15 Jan 90 15:49:07 GMT
References: <7413@drilex.UUCP>
Organization: Evans & Sutherland Computer Corp., Salt Lake City, Utah
Lines: 30

From article <7413@drilex.UUCP>, by dricejb@drilex.UUCP (Craig Jackson drilex1):

> But relocatibility
> would be essential for almost any Unix-like operating system, and I would
> suggest that an MMU is necessary for anything which wants to implement
> fork() while allowing two tasks to occupy memory at once.
> 
> What's more, once you code a 68k for relocatibility in the absence of an
> MMU, it begins to look much more like a segmented architecture.
> 
> My conclusions from all this:

My conclusion is that you've never heard of a relocating loader. I
didn't say linker, I said loader. It is pretty easy for a linker to
build executable modules that contain no absolute addresses. The
loader can then decide where to put the module in memory and back
patch the absolute addresses into the in memory version of the module. 

The back patching operation can be pretty quick, but it does slow down
program loading and you pay for table space in the disk copy of the
program. The point is that you can relocate programs at load time with
no runtime penalty, no weird coding style for relocatability, and no
MMU. 

			Bob P.
-- 
              Bob Pendleton, speaking only for myself.
UUCP Address:  decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet

                      X: Tools, not rules.