Re: [MiNT] virtual address spaces

[Mark Duckworth <mduckworth@atari-source.com>]

On Thu, 2005-12-08 at 01:40 -0600, Evan Langlois wrote:
> Oh, I'm up too late again toying with odd ideas.  A virtual address
> space for systems with an MMU would provide quite a few improvements in
> certain areas of the MiNT kernel.  However, no one has yet implemented
> such as its quite a large project.  I think it may be possible to do so
> one piece at a time.
> 
> If we assume that managing the page tables to do this properly is too
> difficult at this time, then their must be a fallback case for non-MMU
> systems anyways, so we can implement this.  I suppose anything from a
> 68010 on up could trap bus errors to do virtual memory, but I'm more
> concerned with a virtual address space than disk swapping.
> 
> So .. would anyone be willing to discuss methods for implementing the
> mmap() call?   Once mmap() is implemented, other parts of the system
> such as Malloc(), Mxalloc, Pexec(), etc, can be modified to use mmap()
> internally.
> 
> The main problem I see is that without an MMU doing shared executables
> is really tough since you can't do copy-on-write pages or anything, and
> that would be a key benefit to put in place.  You can do base relative
> addressing, but if I remember there was a 64K limitation for offsets
> isn't there?   I was thinking with enough compiler support, you could
> emulate page tables in software on a module-by-module basis keeping each
> module of code under 64K.  Jumps within a module should be fine, but
> jumps between modules would look up the function to call through a table
> which the OS would have to provide to each process.  Heap data
> (everything not in a register or on the stack) would also have to be
> accessed through such tables so the OS can allocate the non-shared data
> segments per-process.  Modules can be shared and linked at run-time as
> long as no function is > 64K.  Shared libraries would consist of
> multiple modules.
> 
> You could even have the OS "swap-out" functions and data from the table
> and replace the table entry for that function with a non-existent
> pointer.  When a BUS ERROR occurs on that pointer, put the task on a
> wait queue, look up that pointer in a table to find the function that
> was swapped out, and swap it back in, then start the process at that
> function.
> 
> Now ... it could all work, but obviously its not going to be as
> efficient and robust as just using the MMU, and you wouldn't need
> compiler teaks to generate all the table lookups.  However, it may be
> doable quicker easier than MMU code and would work on a plain 68000.
> I'm just interested in your thoughts at this point.

Unfortunately, while I do not have the skills to render proper
assistance, I'm a large fan of the simple implementation.  For me it
seems like there's 3 ways to do things:

1. not at all.  Our chosen route.
2. Create a hacked implementation fast.  Whatever is implemented should
follow proper api's but behind the scenes could be a brutal brutal hack.
The method specified above has a hack sound to me but again I DO NOT
KNOW ;)
3. Create the absolute proper implementation all at once.  Our ideals to
follow number 3 I feel lead us to number 1.  In my opinion crap is
better than nothing.  (that's how GIM was born ;) ).

Thanks,
Mark