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.