Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mimsy!eneevax!iarocci From: iarocci@eneevax.UUCP (Bill Dorsey) Newsgroups: comp.sys.atari.st Subject: Re: Forwarded message Message-ID: <539@eneevax.UUCP> Date: Sun, 4-Jan-87 03:15:07 EST Article-I.D.: eneevax.539 Posted: Sun Jan 4 03:15:07 1987 Date-Received: Sun, 4-Jan-87 05:38:05 EST References: <8701022135.AA07189@ucbvax.Berkeley.EDU> <7472@utzoo.UUCP> Reply-To: iarocci@eneevax.UUCP (Bill Dorsey) Organization: never Lines: 27 In article <7472@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Doing any form of Unix on the ST is hard because of the lack of MMU. The >IBM PC, revolting though it is, does have the half-baked excuse for an MMU >that the 8086 itself supplies. Unix on the ST is not impossible, just a >lot of work and rather awkward -- fork() is the bad part on a system with >no relocation hardware. >-- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,decvax,pyramid}!utzoo!henry I beg to differ. If mimix runs on an 8086 system, it could be ported to a 68000 system with little difficulty. If, as I gather you believe, mimix were to use segments for processes, it would require that 64k be the minimum and the maximum limit for all processes. That would be ridiculous! Contrary to popular belief, an MMU is not critical for all multi-tasking oper- ating systems. If the operating system doesn't implement virtual memory, it can function quite well without an MMU. There are quite a few examples of operating systems falling into this category. In summary, if you are willing to put up with processes being able to read each others address space as well as write to it, and virtual memory isn't needed, then an MMU isn't all that critical. Properly functioning processes wouldn't access memory outside of their address range, anyway. The practical effect might be more frequent crashes during the debugging stage of programs as opposed to core dumps. But under normal use, you wouldn't notice the difference!