Unix without an MMU

Thread View: net.micro.atari

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Mark Crispin Mon, 06 Jan 1986 08:51

#1899

Author: Mark Crispin
Date: Mon, 06 Jan 1986 08:51

48 lines
2907 bytes

     Instead of flaming about whether or not Unix* can run
without memory management, why not examine the actual problem.
Bringing up whether or not OS-9 can run without an MMU is silly.
That's like saying that since both wood and gasoline burn, you
can put logs in your car's gas tank.

     Most people consider Unix to comprise a full Unix
environment including all the system services and multiprocess
facilities provided by a Unix system.  In other words, a shell
and some package that emulates Unix system calls is *not* Unix.
If you have multiple processes running in a non-memory managed
system, you are restricted to one of the following:
 . each process absolute-assembled into a different partition of
   memory (ala DEC RSX-11)
 . only one process in memory at a time -- each process swapped
   out when it blocks or its quantum expires
 . all software assembled to perform all memory references
   indexed by a base register, which is loaded by the operating
   system and which the program must not change (ala old IBM OS)

     These are big problems.  Remember, anybody can write
software that does 90% of what Unix does without any of these
problems.  It's called CP/M or MS-DOS or DOS-II or GEM or TOS or
OS/A+ or...ad nauseum.  It's that last 10% that's difficult.

     To be honest, I believe it is more economical to upgrade an
ST to have an MMU than to do the required software hacking.  What
about the license cost?  Gee, I'd think if you are going to fork
over for a Unix license you might as well get a more competant
engine to run it!

     This isn't to say that some clever individual couldn't
do something about "Unix for the ST".  I'd suspect that what
would be presented is a Unix-lookalike environment with some
shell and the Unix system calls, but not a real Unix.  It's that
last 10% all over again...

-- Mark --

* Unix (TM) is a trademark of Bell Labs to describe the
absolutely terrible operating system they have conned large
segments of the computer industry to adopt simply because there
is no other portable operating system with the necessary
facilities.  It also describes the philsophy of those individuals
who wish to make computers mysterious to the general public again
after 20 years of effort to make computers understandable.
-------

Re: Unix without an MMU

#1902

Author: Daryl Monge
Date: Mon, 06 Jan 1986 15:27

21 lines
1284 bytes

> If you have multiple processes running in a non-memory managed
> system, you are restricted to one of the following:
>  . each process absolute-assembled into a different partition of
>    memory (ala DEC RSX-11)

Not altogether true.  If you process activator can handle relocation
information in an executable file, you can have multiple processes without
memory management.  I see no reason why UNIX would not run.

Still, I agree with the opinion that it is much preferable to run with
an MMU for protection.  It is cheaper to add an MMU than to spend alot
of development time getting around its ommision.

Rumor has it that the TT is the correction for this.


Daryl Monge
AT&T
Bell Labs, Naperville, Ill

...!ihnp4!ihelp!dlm

Re: Unix without an MMU

#1910

Author: Mitch Bradley
Date: Mon, 06 Jan 1986 17:55

33 lines
2280 bytes

> If you have multiple processes running in a non-memory managed
> system, you are restricted to one of the following:
>  . each process absolute-assembled into a different partition of
>    memory (ala DEC RSX-11)
>  . only one process in memory at a time -- each process swapped
>    out when it blocks or its quantum expires
>  . all software assembled to perform all memory references
>    indexed by a base register, which is loaded by the operating
>    system and which the program must not change (ala old IBM OS)
>    ...Mark Crispin

I know of one other alternative:
The binary file can contain a relocation list which identifies locations
that need to have a base address added when the program is loaded into
memory.  When the program is loaded into memory, the load function ("exec"
in Unix terminology) relocates these addresses before the program is started.

This is exactly what TOS does.  The relocation list is stored as a stream
of byte offsets to the next longword that has to be fixed up.  There is
a reserved byte value that skips without relocating, so it is possible to
relocate any program with less than 25% file storage space overhead.
The maximum overhead would only occur if every single longword had to be
relocated.  A typical C program requires much less overhead, below 5%.

It does take some time to do this, but not very much; the time is not 
noticeable compared to the disk access time necessary for loading the
program.

It seems to work pretty well in TOS.  Of course, one program can disable
another by writing to memory that it doesn't own, but that is a separate
issue.

Mitch

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads