🚀 go-pugleaf

In article <380@bambam.UUCP> bpendlet@bambam.UUCP (Bob Pendleton) writes:

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

In response to this, in article <44106@wlbr.IMSD.CONTEL.COM>
sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz) writes:
|	and of course the same thing can be done when a process is
|	swapped out and reloaded later at a different memory location?
|
|	a relocating loader sounds like only a part (the easy one) of
|	the solution.  there's more to do than just loading the program
|	the 1st time.

You might want to have a look at the MINIX port to the Atari ST.
I think that is an implementation of the scheme that Bob is talking about.
An ST has no MMU, programs are relocated during the exec().
I don't think you should try to think of relocating a program once
it has been running for a while. You have no way of knowing what it is
doing with pointers.
When you run a unix-like system, there is one additional point where
this scheme slows the system down, in addition to the relocation work
during program load.
As Craig noted, when the program fork()s, you have two programs that need
to be located at the same virtual (== physical with no MMU) address space
to run, so for every context switch, you must check whether the program is
at the proper place and if not, swap things around (in memory, not necessarily
to disk), which dramatically increases context switch overhead.
Fortunately, this is normally not much of a problem, since usually a program
does an exec() shortly after the fork() and this exec() can fix the problem.

This scheme is not very elegant, but it allows one to run a unix system
on hardware like ST, Mac and Amiga.

-- 
	Willy Konijnenberg		<willy@idca.tds.philips.nl>