Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: OS/2 vs AmigaDOS
Message-ID: <6758@cbmvax.UUCP>
Date: 3 May 89 18:34:19 GMT
References: <16952@usc.edu> <7988@killer.Dallas.TX.US>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 30

In article <7988@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes:
>in article <16952@usc.edu>, papa@pollux.usc.edu (Marco Papa) says:
>> Do you mean 1.4 will support virtual memory and will show up by year's end?
>
>Sorry Marco. Virtual memory is no problem. Process protection
>(GURU-busting) is. AmigaDOS assumes one big huge shared memory address
>space with multiple cooperating programs occupying it. Process
>protection thus must be on a per-block basis, which the MMU on the
>2620 will NOT do if I recall my Motorola MMUs correctly. Virtual
>memory, on the other hand, is a piece of cake by comparison. Just map
>in the CHIP and ROMs, map in your page faulter (which runs the hard
>disk handler in "real" mode), and presto -- instant multi-megabyte
>FAST.  Or not so presto... there's some problems involved in getting
>your pages to and fro from the hard drive. But you get the picture.
>There's no major OS rewrite or major hardware modification involved,
>just a bit of (admittedly tricky) software to control the hardware
>already there, in a way totally transparent to applications programs
>(when they request FAST, they have no idea if it's "really" memory, or
>not). 

	Actually, it's tougher than that.  Forbid()/Permit() locking is no
longer sufficient if you need to take a page fault in the middle of it.
Let's not talk about Disable/Enable.

	On the other hand, non-transparent VM is easy (where the program has
to ask for it explicitly.)  You just make sure you don't access VM pages
during Forbid/Disable.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup