
Memory

the interpreter is initialised with a single memory image, into which
we have to map: the internal ROM, the newtonscript frames heap, and
any parts of the system domain which the interpreter ends up being
aware of (like the entry cache, etc).

the content of both the ROM and the frames heap consists completely(?)
of newtonscript objects.  this is useful, since we can therefore
structure this area as more than a dumb string of bytes, and use the
additional info for garbage collection, etc.

the newton datatypes stored are: frames, arrays and maybe magic
pointers (i think).  within these the other datatypes are also
possible (ie. integers, etc).

so, the memory implementation will have several operations:

1. resolve pointer, returning the target object.
2. address of, returning a pointer to the target object
3. create magic pointer, in the specified table, to the specified object(?)
4. resolve magic pointer, returning target object.
5. make new object
6. clone object (and deep clone)


on boot (which will be somewhat different for gnuton compared to NOS),
we will have to initialise the pseudo-ROM and the internal store.
it's not clear how the messagepads dealt with an initial boot: we can
conjecture

1) jump to XXXX in ROM, and begin ARM assembler execution of the boot
   loader.
2) boot loader initialises memory management, and starts the runtime
   system.
3) runtime starts, and initialises all the device drivers, etc.  at
   this point, the hardware is basically ok.
4) i *imagine* that if the internal store (flash) is empty, there's a
   ROM routine which initialises it as a store, creates the required
   soups (packages, system, etc), and initialises the soup contents
   from default values in ROM (this would include the pointers to the
   ROM applications in the packages soup, default values for the
   system soup, etc).
5) activate the packages in the (newly setup) package soup.
5) find the blessed app (is this a global variable?), find its base
   frame, and :Open() it ???



so, in GnutOS:

1) we boot and run through the hardware setup stuff, basically
   figuring out what it is we're running on.
2) we need a ROM image.  exactly what *format* this will be is an
   interesting question.
3) we need an internal store host device, optionally with a store
   image already on it.
4) we need a frames heap, and optionally, an image to initialise it
   from.


but, lets look at the initial boot first, since that's what we'll be
doing first ;-)

i think both the ROM image and the frames heap can be groups of the
basic data classes, linked together into a pickle-able structure.
the VM instructions make-frame, make-array, add-slot, clone, etc cause
the allocation of new memory objects.  the MemoryManager should
allocate these, ensuring that it is able to pickle/restore them
successfully and also garbage collect them (!)

something (the VM?) has to be able to resolve magic-pointers too.  the
table number will have to cause a lookup of a well-known array, i
think.  where these are stored, and how this works with unit imports
isn't clear to me yet.
