🚀 go-pugleaf

A couple of remarks:

1) P0 grows upwards from 0 and is where text, initialized data, and statically
allocated uninitialized data are normally placed. Most libraries also put
dynamically allocated data (malloc/free, etc.) in P0, but, if you're careful
about your stack space, you can use P1 for dynamically allocated data (i.e.,
the stack pointer need not be the low end of P1 space).

2) P1 grows downwards from the middle of the address space, and is usually
used for the stack, which the hardware instruction manage by moving towards
lower addresses on pushes and calls, and higher addresses on pops and returns.
One can allocate beyond the end of the stack (but be aware that at least a few
words beyond the end of the stack may be used for emulation scratch space
(e.g., floating point instructions not supported directly in hardware)).

3) Kernel space is the third quarter of the address space, as previously
noted, and is generally shared among all processes (but pages have different
protections in user, exec, supervisor, and kernel modes, so this is safe,
etc.)

4) The fourth quarter of the address space is generally used for I/O devices
and could be called "I/O space", though I am not sure if that is an "official"
designation.

I have participated in the design and implementation of user mode threads
packages, and we found we can place the multiple stacks in either P0 or P1
space with no particular problems. The only way in which the spaces tend to
impinge on design is this: all pages in P0 space up to the highest one
allocated, and all pages in P1 space down to the lowest one allocated, MUST
have a page table entry (PTE), even if it is set no access. The memory
management hardware on many other machines allows sparse allocation, but the
hardware on the VAX precludes that, and ultimately every page you have
impinges on non-pageable kernel space (the page tables for your page tables),
so this resource tends to be jealously guarded by any operating system,
meaning you have to be careful about you allocate things for some kinds of
languages (e.g., it's not as nice for heap management in a LISP system, etc.,
as one might prefer).
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu