[MiNT] Virtual memory design

[Henk Robbers <h.robbers@chello.nl>]

LS

Based on very unspecific general knowledge of virtual memory.
I have no idee whether these thoughts have any practical value.
The 3 idees are independant of each other.
They heve nothing to do with today implementations.

-------------------------- 1 ----------------------------
It should be possible to completely disentangle a virtual
store manager (VSM) from the actual operating system.

Implement a VSM as a bottom layer underneath anything else.

A VSM is the only part of the software that runs in physical
address space. It is booted first.
When booted it prepares a swap file and sets up a page tree
describing all left over memory in which to load the first
program.
This program could be anything, so why not a operating system.

The OS runs in virtual memory all the time.

The VSM only needs a few functions:
1 Create a virtual addres space of a given size.
2 Extend a given virtual address space by a given amount.
3 Contract a given virtual address space by a given amount.
4 Destroy a given virtual address space.

These function are made available via software interrupts
(classic system calls).
The VSM only needs to know about address spaces.
Processes are OS concepts.

The functions of a VSM are only available in kernel mode.
The VSM functions are used by the kernel for its own requests
and to accomodate memory requests from user code.

A certain amount of the OS virtual address space can be mapped
to physical address space to accomodate refering to page trees,
interrupt vectors and other things depending on architecture.

It is easy to make a version of a OS for use without such
a VSM. Just implement simple versions of the VSM calls in
the OS itself.

---------------------- 2 --------------------------

A nice idee would be for a OS to be able to keep
its memory model flat, including all user code.

This can be achieved by doubly mapping user memory.
Once normally and once in the address space of the OS,
such that the virtual address space of a user process
is part of the OS address space as continuous adjacent
virtual memory regions.
The only thing the OS need to know is the start address
and size. (Datum & limit in certain old mainframes).
Locations within those address spaces can be
refered to by the OS through simple indirection.
Extending address space only needs updating page trees.

It makes sparse memory look dense.

In this case the VSM needs appropriate paramaters to its
functions.

The model is not suited for clumsy implementations of
shared or public code. Especially not when fixed virtual
addresses are used.
It is not suited for 'top of address space' stacks as well.

------------------------- 3 --------------------------------

Another nice idee would be to implement segmentation.

The first level page table is the segment table.
The first 10 bits of the address is the segment number.
Segment displacements start at 0 and are maximuum 4Mb.
Due to lack of a segment linit field, the segment size is
determined by the number of valid 2nd pagetable entries.

Segments can be shared by address spaces.
The 2nd level page table describes the same pages, but the
segment number can be different. All segments start at 0 :-)

Malloc OS chunks are a new segment each. As is the stack.
The stack must grow upwards so it actually *can* grow.

Henk Robbers