initial mimi; recursive factorial demo

[muddle.git] / doc / mim.md

diff --git a/doc/mim.md b/doc/mim.md
index 664cbaaabe848eb61345c54395f323fa0181d723..2c5012dcbab7788eae9c6ec0929cb4a3d5ef8175 100644 (file)
--- a/doc/mim.md
+++ b/doc/mim.md
@@ -248,3 +248,39 @@ The bulk of the GC (marker/sweeper, compactor) can be written in MIM,
 and run in an internal PROCESS, though some fundamental ops need to be
 compiled for a particular type of GC implementation (because hooks for
 allocation and read/write barriers need to be as fast as possible).
+
+# Loading MIM Libraries
+
+Usually a whole library (like the stdlib) is statically linked into
+one file, but per-file dynamic linking is also possible.
+
+Run some code from the file, typically a standard loader in the
+header--the loading process is up to the MIM code.
+
+Standard loader needs to, at minimum:
+- lookup some ATOMs from const STRINGs
+- SETG those ATOMs (to LAZY.UBLOCK stub objects or upfront-loaded RVECTORs)
+
+On a MSUBR's first call (or earlier), it's necessary to:
+- create its RVECTOR, including its CODE object
+
+File will look like:
+[ module loader CODE ]                (not needed after load)
+[ STRINGs for ATOMs defined on load ] (not needed after load)
+[ RVECTOR loaders... ]                (const, each needed once)
+[ MSUBR CODE... ]                     (rw, persistent)
+
+--if we use the CODE in-place (as mmap'd), the GC can ignore it completely
+RVECTOR loaders:
+- all at once?
+  - much more efficient if we're going to be running them all anyway
+  - section becomes droppable
+  - simpler
+- lazily?
+  - work scales with functions called, not functions available
+  - have to mmap in low-space to make the CODE directly accessible
+- it's up to the loader; initial impl will be upfront
+
+MSUBR calls in a MSUBR can be:
+- unlinked: ATOM in RVECTOR, NTHRGL to look up current value each call
+- linked: MSUBR in RVECTOR, set up by loader