MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) (01/06/86)
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.
-------dlm@iheds.UUCP (Daryl Monge) (01/06/86)
> 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
wmb@sun.uucp (Mitch Bradley) (01/06/86)
> 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
dan@BBN-PROPHET.ARPA (01/07/86)
Mark Crispin's message did indeed list all the practical or semi-practical ways to implement Unix w/o an MMU. The people who responded to his message don't seem to understand what the Unix fork() system call does; the Amiga TOS method will not work in Unix. The fork() system call, remember, generates a new process which is an EXACT COPY of the old process. Any pointers in the old process's data are copied to the new process. But the semantics of fork() require that those copied pointers now magically point to the COPY of the data in the NEW PROCESS. Mark's message listed all the possible ways this could be accomplished w/o MMU, save one, which is to somehow figure out which random words of data in the data space are pointers and readjust them at fork time. This is quite impractical, as anyone who knows something about C will realize. As an aside, the Sage IV 68000 system had no MMU, and did run Unix. Or rather, it ran IDRIS, the Unix look-alike (which does have a Unix-style fork()). I don't know which of the methods Mark listed they used, but I suspect the first one: running only one process at a time in memory, and swapping it out before starting another one. At any rate, let the Sage IV be the existence proof that you CAN run Unix w/o an MMU, and let Mark's message be the explanation of how, and let's get on with topics more closely related to the 520 ST, which I don't believe will ever run Unix (though something else from Atari might). Dan Franklin (dan@bbn-prophet.arpa)
erich@cory.BERKELEY.EDU (nnamrreH cirE) (01/08/86)
There are several implementations of UNIX-like operating systems,
with multitasking, on the MMU-less IBM PC and compatibles. However
it is done, it seems to be at least nominally compatible with UNIX.
What methods are used here? Could they be applied to a 68000-based
system? Am I missing the point entirely? (Perhaps PC UNIX's
fork() does NOT act like real UNIX.)
Ranjit Bhatnagardave@enmasse.UUCP (Dave Brownell) (01/10/86)
It was recently asserted here that UNIX runs on the IBM PC without an
MMU. Well ... sort of.
The segment registers can be used as an MMU, if you keep programmers
from using them. Since that can't really be done on an 8086/88, PC/IX
(and VENIX, Xenix, ...) on IBM PCs doesn't really count as secure.
(Ergo it's not UNIX.) Processes can mangle each other at will.
In short, it's not really UNIX there, and it pretty much DOES have an
MMU. Better than nothing, but I wouldn't buy it. UNIX needs at LEAST
memory mapping. This can be real cheap! but the 520ST doesn't have it.
--
David Brownell
EnMasse Computer Corp
...!{harvard,talcott,genrad}!enmasse!davecollinge@uvicctr.UUCP (Doug Collinge) (01/12/86)
In article <8601071639.AA03270@ucbvax.berkeley.edu> dan@BBN-PROPHET.ARPA (Dan Franklin) writes: >As an aside, the Sage IV 68000 system had no MMU, and did run Unix. Or rather, >it ran IDRIS, the Unix look-alike (which does have a Unix-style fork()). I >don't know which of the methods Mark listed they used, but I suspect the first >one: running only one process at a time in memory, and swapping it out before >starting another one. I have IDRIS. It does have fork(). It can run more than one process in memory at once and usually does but after a fork it runs the parent and child in the same space by swapping. Of course, as soon as you do an exec (most of the time right away) it gives you a new space and the swapping stops. This is entirely practical and works just fine. I see no reason why a similar system couldn't work on the ST - but it couldn't be SysV or 4.2 because some of the calls require memory mapping, e.g. realloc(). -- Doug Collinge School of Music, University of Victoria, PO Box 1700, Victoria, B.C., Canada, V8W 2Y2 decvax!nrl-css!uvicctr!collinge decvax!uw-beaver!uvicctr!collinge ubc-vision!uvicctr!collinge
john@anasazi.UUCP (John Moore) (01/12/86)
In article <11372@ucbvax.BERKELEY.EDU> ranjit@bugs.UUCP (Ranjit Bhatnagar) writes: >There are several implementations of UNIX-like operating systems, >with multitasking, on the MMU-less IBM PC and compatibles. However >it is done, it seems to be at least nominally compatible with UNIX. >What methods are used here? Could they be applied to a 68000-based >system? Am I missing the point entirely? (Perhaps PC UNIX's >fork() does NOT act like real UNIX.) > > Ranjit Bhatnagar We have several Unix systems (not Unix-like) running on the PC. They are VENIX (Unix V-7), VENIX-V (Unix System V), and PCIX (Unix system 3). These are all AT&T licensed Unix's and work the same as one other systems (we also have a CT Megaframe running UNIX System-V, and we port back and forth all the time). However.... These Unix's DO have the use of limitted MMU capability. The 8086 family has a (disgusting) memory management scheme which uses base registers. All programs which use less than 64K dataspace are relocatable by simply changing the contents of the base registers. This is better than absolute addressing in that even pointers are relocated. It also adds the very severe limitation of 64K data spaces. I agree tha`i MMU's would be nice on the ST. However, it is possible to make a UNIX (or something very close to it) without MMU's. -- John Moore (NJ7E/XE1HDO) {decvax|ihnp4|hao}!noao!terak!anasazi!john {hao!noao|decvax|ihnp4|seismo}!terak!anasazi!john terak!anasazi!john@SEISMO.CSS.GOV (602) 952-8205 (day or evening) 5302 E. Lafayette Blvd, Phoenix, Az, 85018 (home address)
john@anasazi.UUCP (John Moore) (01/14/86)
>(and VENIX, Xenix, ...) on IBM PCs doesn't really count as secure. >(Ergo it's not UNIX.) Processes can mangle each other at will. ^^^ ^^^^ Nonsense! It works find as UNIX. It is true that it is not hacker protected, but most single computer UNIX's have only one user anyway. To me UNIX is a portable environment offering a wide selection of nifty tools. That's just what I have here on my VENIX. > >In short, it's not really UNIX there, and it pretty much DOES have an >MMU. Better than nothing, but I wouldn't buy it. UNIX needs at LEAST >memory mapping. This can be real cheap! but the 520ST doesn't have it. ^^^^^^^^^^^^^^^ You just haven't shown this. The extreme purist view that PC UNIX's aren't really UNIX doesn't wash. On the other hand, there is no denying the value of memory mapping > >-- >David Brownell >EnMasse Computer Corp >...!{harvard,talcott,genrad}!enmasse!dave -- John Moore (NJ7E/XE1HDO) {decvax|ihnp4|hao}!noao!terak!anasazi!john {hao!noao|decvax|ihnp4|seismo}!terak!anasazi!john terak!anasazi!john@SEISMO.CSS.GOV (602) 952-8205 (day or evening) 5302 E. Lafayette Blvd, Phoenix, Az, 85018 (home address)