Re: Virtual Memory

[Dancer <dancer@ozspace.brisnet.org.au>]

---------- Forwarded message ----------
Date: Wed, 15 Feb 95 09:02 EST
From:MAILER-DAEMON@ozspace.brisnet.org.au
To: dancer@ozspace.brisnet.org.au
Subject: mail failed, returning to sender

|------------------------- Failed addresses follow: ---------------------|
 mint@terminator.rs.itd.umich.edu ... transport smtp: no connection to remote SMTP server: 499 timeout on read from remote SMTP process
 dvasilef@copper.ucs.indiana.edu ... transport smtp: no connection to remote SMTP server: 499 timeout on read from remote SMTP process
|------------------------- Message text follows: ------------------------|
Received: by ozspace.brisnet.org.au (Linux Smail3.1.28.1 #14)
	id m0reWBR-0007KSC; Wed, 15 Feb 95 08:57 EST
Date: Wed, 15 Feb 1995 08:51:18 +0000
From: Dancer <dancer@ozspace.brisnet.org.au>
Subject: Re: Virtual Memory
To: David Vasileff <dvasilef@copper.ucs.indiana.edu>
cc: mint@terminator.rs.itd.umich.edu
In-Reply-To: <Pine.3.89.9502141959.A5993-0100000@copper.ucs.indiana.edu>
Message-ID: <Pine.3.87.9502150817.A942-0100000@ozspace>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 14 Feb 1995, David Vasileff wrote:

> > VM _can_ be performed on a 68000. I used to have the code for it.
> 
> [stuff edited]
> > 
> > 	char **ptr;
> > 
> > 	ptr=VMalloc(8192L);	/* Allocate a virutal memory block */
> > 	VMunswap(ptr);		/* unswap region until we say otherwise */
> > 	strcpy(*ptr,"Test data"); /* store something in it */
> > 	VMswap(ptr);	/* done with this block for now, it can be 
> > swapped if the VMM wants to. */
> 
> so is this user code?  if it is, this is no solution at all as far as an 
> OS is concerned.  this looks like some sort of overlay system to me.

	Yes, that's user code. VMalloc(), VMfree(), VMswap(), VMunswap(), 
and VMderef() were all our own added kernel functions to do the dog work. 
The debate is running in two parts. (1) That it can't be done, (2) That 
you would need two kinds of executable to cover VM and non-VM options. 
Neither of these is in fact the case. There is no way to solve both 
problems quickly, though....part 1 is slow, and part 2 slows down those 
machines that already can do VMM.

	In short, you can have your VMM in the kernel, and running on a 
68000 if you want to. It's quite possible, and not terribly difficult to 
implement...but IT IS _SLOW_.

Dancer

--
---------------------------------------------------------------------------
|   /----\   |GAT -d++()(--)>!d H s++: g+ p1+ !au a-? w+++(--)
|  /  //  \  |v---(-)*(++) c+++@>$ U?++++$>B++++$>S++++$ P+(-) L- 3-
| |  //  //| |E--- N++(+++) K W---() M(+) V--@ -po+(--@)(++@) Y+ t(+++@)
| | //  // | |!5 !j R+++()>$ G+ tv(-) b+++ !D B(-) e u++(*)
|  \/  // /  |h++(-)(---)>*$ f+(?) r--@(+++@) n----(--) y+++(++@)>*>**
|   \----/   |-------------------------------------------------------------
|            |   dancer@ozspace.brisnet.org.au
---------------------------------------------------------------------------