Path: utzoo!attcan!uunet!lll-winken!lll-tis!oodis01!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (Every system needs one)
Newsgroups: comp.sys.amiga
Subject: Re: Amiga UNIX
Summary: Ut-uh.
Message-ID: <548@wsccs.UUCP>
Date: 28 May 88 04:40:37 GMT
References: <211@laic.UUCP> <3663@cbmvax.UUCP> <1872@sugar.UUCP> <134@ssdis.UUCP> <237@obie.UUCP>
Lines: 26

In article <237@obie.UUCP>, wes@obie.UUCP (Barnacle Wes) writes:
> When the processor wants to store/load to/from memory, it requests the
> location from the MMU.  The MMU looks up this VIRTUAL address in a table
> of PHYSICAL ADDRESSES, and then reads or writes the physical RAM as
> appropriate.  This table lookup is called a TRANSLATION.
> 
> Usually, there is a table for the system and one table per user process.
> With this scheme, each process has it's own address space, so each
> process' memory can start at VIRTUAL address 0.  BTW, virtual addresses
> are all you'd ever see in user mode.

Not necessarily so, Wes.  You're forgetting about mapping memory-mapped I/O
into a users address space, which is one of the many half-baked things a
message passing operating system will do for you.  Without the niceities
of clist structs and what we in the software business like to call "usable
interrupts", things like to write directly into your data segment.  VMS
does this too, more's the pity.  When you do this, the MMU always maps
your address to a known location in memory, and that location is never
altered via swapping.  Unf---ingortunately, Commodore had the idiocy to
use a 68000 instead of a 68010 or 68020, just like Atari, so neither
machine can properly support an MMU and are therefore not socketed, so the
whole thing is moot, anyway.  There will never be a good vmunix for a
68000.

Now if you were to replace your 68000 with a 68010...

						terry@wsccs