Re: Virtual Memory

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

On Tue, 14 Feb 1995, Hartmut Keller wrote:

> 
> On Tue, 14 Feb 1995, Stephan Haslbeck wrote:
> 
> > [...]
> >
> > I think it will be very diffcult (if not even impossible) only to implement 
> > some simple way of swapping on 68000s. It's just the missing MMU. All 
> 
> Just a silly idea: how about placing the program in memory regions
> that create bus errors and converting the addresses in the bus error
> exception routine? Well, forget it, it'd be terrible slow.
> 
> > programs would have to know that their pointers might change and some 
> > memory they just accessed is not valid any more. Maybe there is a way of 
> > putting this into the MiNTLibs. But it will be hard work, no question. 
> > And porting programs will be even harder, because most programs rely on 
> > non changing pointers.
> > 
> > I have a good old 520 ST, also. I won't have any use of VM on it, too. So 
> > should we leave it all as it is? A program that won't run in 4 MB on an 
> > 68000, won't run in 4 MB on an 68030 without VM either.
> I think a MiNT with VM, swapping and shared libraries (ok, I'm
> dreaming away, but who cares? :-) ) is always an alternative to Linux.
> And as all those 68030'ers stay at MiNT instead of converting to Linux
> the 68000'ers have their advantage too: further development of MiNT
> and MiNT aware software. Even if it runs slower or less comfortable on
> their machines. In a little time MiNT without VM will be no competitor
> to Linux anymore.
> 
> > I don't think someone will try to port Linux to 68000s, so for 68000 
> > users MiNT is the only way to get some Unix compatible OS. VM then is 
> > only a gift for those who have newer CPUs.
> 
> So I absolutely recommend implementing VM into MiNT as (in my opinion)
> it is the only future of MiNT.


VM _can_ be performed on a 68000. I used to have the code for it.


In unswapped memory you have a table of pointers. The size of this table 
limited the number of VMalloc()'able regions available. Each of these 
pointers obviously points to a memory region.

VMalloc() returns a pointer to one of these pointers. This enables the 
memory region to be moved around in memory at will, so long as the region 
returned by VMalloc().

To ensure that the memory region is not swapped out when you try to 
access it, you fetch it with VMaccess(), which does the dereferencing, 
and unswaps the region as necessary.

At the cost of some overhead, you can link this to 68030 VM management, 
and still works on a 68000. If slowing your accesses doesn't concern you 
much, then this is one way to go. As an alternative:

	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. */

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
---------------------------------------------------------------------------