The OS will most likely have an interpreting Lisp shell.
Potentially later this could be extended to a compiler.
Based on Make a Lisp.
All objects are aligned to even addresses. Objects types are encoded either inline in a pointer, or through a special value of the first word.
The following list is loosely based on MAL's types
- Nil (encoded inline)
- Small int (encoded inline)
- Cons
- String
- Symbol
- pointer into symbol table
- Keyword
- symbol automatically evaluates to itself
- Atom (MAL step 6)
- Hash
- List (?)
- Native function
- Closure (MAL step 5)
- Bool?
- MAL uses separate true and false types
- common lisp seems to have symbol t that evaluates to itself
- maybe use true and false symbols evaluating to themselves, treat false and nil as false, everything else as true
0000 0000 0000 0000: NILxxxx xxxx xxxx xxx0: Pointer to objectxxxx xxxx xxxx xxx1: 15bit immediate signed integer
- Copying GC
- Two generations
- Object mutability is a problem:
- All values could be RO
- Too limiting?
- Mutation of an older generation object could cause an immediate GC of the nursery area (with one extra root)
- We could keep a list of old generation objects that will serve as additional roots for nursery GC
- This could be just a Lisp list held with a single global pointer
- All values could be RO
- Object mutability is a problem:
- Eventually the "new" space could be limited to only two pages with some and manipulation of memory maps
- Allows to use almost the full 64k space for the working data, not just half
- Additional 64k of physical memory would be necessary for GC
- Only paid once for all interpreter instances, if the OS supports it (no process switch during GC)
- Additional 64k of physical memory would be necessary for GC
- Allows to use almost the full 64k space for the working data, not just half
- Eventually the OS could remap old generations as RO and provide a callback to the GC in case there is a change to older data.