Ha3sm memory management
There's one bus. This is the fundamental concept of Ha3sm. One bus maps
to one timescale, which is what one OS manages. If it has more than one
bus it's a network protocol.
On a Pentium it's 32x64 bits, address/data. A cell on a Pentium
is thus 32 bits. The point of a cell is that on one bus there can
be several cell sizes. As mentioned in axioms, Ha3sm will be
CPU-heterogenous fairly transparently on one bus. cell,
endianism, and complement (1's or 2's) are system
constants per system.
0wner
process(or)s can see all memory. There should be a system variable
set at boot somewhere for how much total RAM there is, and that's a bit of
code to generate on a PC.
Guest process(or)s must be restricted to guest rooms
within RAM. This involves an allocator and a hardware-supported
permissions supervisor. The allocator contemplated is simple, geared
to infrequent requests for large contigua of memory.
There won't be any brk() equivalent as such. Allocations will only occur
at login, which is when all process(or)s are spawned, and
deallocations will only happen at logout, which may be voluntary
or may be the result of action analagous to kill() by the supervisor.
In unix-ese, Ha3sm login does fork()/execve(), but the address-space is
not replicated by the fork, the new process is an 0wner process and isn't
sequestered, OR does the one possible brk() equivalent it will get a
chance at, at that is it's total allocation, and said guest can move in
and can run if the brk()-equivalent succeeds, otherwise no. And you get
exactly what you ask for, plus some block-rounding.
ALLOCATOR
best halfmax fit
Processes will request a specific memory allotment at login, not a range.
That will be rounded up to a system bus block size and sought from the
allocator. If the request exceeds half the expanse of the largest
contiguum currently available (halfmax) the process will be
refused existance. If the process's request isn't too big, a justified
best fit is sought. An exact match between the process's rounded-up
request and a vacated slot is an automatic allocate. That is, if the
request can be justified at both ends AND is smaller than halfmax then no
further checking is required. Otherwise the smallest slot is taken, and
the allocation is justified to the one end of the slot closest to an
overall end of memory in the allocator as a whole. Without paging we don't
really have a system block size, so pick one.
The bounds of each segment probably want to be kept in a list. On x86
that can be the GDT and it's various "segment present" bits, I believe.
This scheme is geared for a few large processes, and is geared to foster
an awareness of resource consumption on the part of application writers.
It looks like it won't run completely out of memory without strange
efforts to do so on the part of the 0wner. In exchange for no
out-of-memory issues, a default guest shell should be kept small. Guest
shells will tend to be vt-like things rather than graphical, so the
default should be small.