m0 memory questions

questions.txt

per-callframe constants segment layout:

constants segment starts with a list of fixed-width pointers.  I/N entries are stored directly.  S/P entries are pointers to later in the constants segment
The data segment has a couple options.  It can be appended after the constants segment (either on the next page or immediately after), with the constants data being marked read-only.  Alternately, it can just be another segment attached to a special register.

If callframes are analogous to subs, the constants and data segment can be analogous to lexical data.

If callframes are analogous to subs, how will recursion work?
 * clone a callframe (when?  before entering ( -> no state) or after entering (less waste, leftover state))
 * need to work out calling conventions

Overall, m0 is a fantastic pain in the ass to write and especially debug.  It needs a handful of features to ease the process.  Possibilities include:
 * basic interactive debugger
 * something to dump (a subset of) the state of a register

unresolved questions: 
 * how will global data work?  Will it be part of m0b or purely runtime?
   * hang it off cf[INTERP][GLOBALS] or something similar
   * it'll need to be dynamic
   * add a .globals segment
 * how can code grow/shrink the rw data segment (sbrk-like op?)
   * alternately, each cf can have a fixed-size data segment.  It'd result in hacks for large functions, but a whole virtual memory implementation wouldn't be needed.
   * does this mean that any M0 implementation needs to implement virtual memory (or virtual virtual memory, as it were)?
   * realloc is a good-enough first approximation
   * alternately, we can have a list of data segments that can be created with alloc
     * this probably adds too much complexity to m0 (not a lot, but a little that can be avoided)
 * is there any value in naming registers [INSP]n at all?  Why not Rn

M0 spec todo:
 * change CONSTS to be a single chunk of memory with internal pointers
 * go with flat memory space + realloc to expand; update the spec to reflect this
 * spec out the op that'll expand/contract the data segment
 * spec out the op that'll expand/contract the globals data segment
 * spec out the globals m0b chunk
 * make the constants segment a read-only part of the data segment
 * make GLOBALS work similar to the constants segment, except that the segment can grow
 * float the idea of untyped register names by nbrown (i.e. I0 = R0, etc)
 * spec out the m0b and runtime representation for hex constants and data
   * In m0b, similar to strings but with a new encoding #
   * In memory, simply a pointer to the data

M0 testing TODO:
 * write out a test that recursively does something (naive recursion-based addition is fine)
 * fizzbuzz, just because
 * tests for special registers
 * test to ensure that constants data can't be overwritten

If there's a sane and simple way to specify macros for M0, I'd love to see them. That said, I'm not sure there's a good way to implement them. They'll probably be easier to add at the m1 level or higher.

I'm +1 on it. :)