Skip to content

Instantly share code, notes, and snippets.

@cotto
Created May 2, 2012 22:52
Show Gist options
  • Save cotto/2581153 to your computer and use it in GitHub Desktop.
Save cotto/2581153 to your computer and use it in GitHub Desktop.
m0 memory questions
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
@cotto
Copy link
Author

cotto commented May 8, 2012

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.

@zhuomingliang
Copy link

I'm +1 on it. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment