Fix up some TODOs

todo.org

@@ -3,39 +3,6 @@
 #+date: 2023-11-02
 #+startup: noindent
 
-* TODO Better documentation [0%] :DOC:
-** TODO Comment coverage [0%]
-*** WIP Lib [75%]
-**** DONE lib/base.h
-**** DONE lib/darr.h
-**** DONE lib/heap.h
-**** TODO lib/inst.h
-*** TODO VM [0%]
-**** TODO vm/runtime.h
-**** TODO vm/struct.h
-**** TODO vm/main.c
-** TODO Specification
-* TODO Do not request for more memory in registers
-The stack is a fixed size object allocated at the start of a program
-and inserted onto the VM.  The VM cannot request more memory for the
-stack if it runs out, but this also ensures a very strict upper bound
-on stack memory usage which can be profiled easily.  Furthermore, the
-code that interacts with the stack can use the strict sizing as an
-invariant to simplify implementation (e.g. pushing to the stack when
-the stack is full will trap the program).  Also the stack cannot be
-used to OOM attack the virtual machine.
-
-Registers are currently dynamic arrays.  Say 8 word registers are
-allocated at init time.  If a user requests a 9th word register,
-memory is requested from the operating system to increase register
-space.  This is unacceptable from both a profiling and an attack point
-of view; it would be trivial to write a program which forced the
-runtime to request ridiculous amounts of memory from the operating
-system (for example, by ~mov.word <very large number>~).
-
-Registers should not be infinite; a standardised size (with a compile
-time option to alter it) ensures the benefits stated above for the
-stack.
 * TODO Introduce error handling in base library :LIB:
 There is a large variety of TODOs about errors.  Let's fix them!
 #+begin_src sh :exports results :results output verbatim replace
@@ -52,7 +19,19 @@ find -type 'f' -regex ".*\.[ch]\(pp\)?" -exec grep -nH TODO "{}" ";"
 : ./lib/base.c:19:  // TODO: is there a faster way of doing this?
 : ./lib/base.c:25:  // TODO: is there a faster way of doing this?
 : ./lib/base.c:32:  // TODO: is there a faster way of doing this?
-* TODO Standard library :VM:
+* WAIT Better documentation [0%] :DOC:
+** TODO Comment coverage [0%]
+*** WIP Lib [75%]
+**** DONE lib/base.h
+**** DONE lib/darr.h
+**** DONE lib/heap.h
+**** TODO lib/inst.h
+*** TODO VM [0%]
+**** TODO vm/runtime.h
+**** TODO vm/struct.h
+**** TODO vm/main.c
+** TODO Specification
+* WAIT Standard library :VM:
 I should start considering this and how a user may use it.  Should it
 be an option in the VM and/or assembler binaries (i.e. a flag) or
 something the user has to specify in their source files?
@@ -70,7 +49,7 @@ Something to consider is /static/ and /dynamic/ "linking" i.e.:
     at the start) so we'll know at start of assembler runtime where to
     resolve standard library subroutine calls
   + Virtual machine needs no changes to do this
-** TODO Consider dynamic Linking
+** WAIT Consider dynamic Linking
 + Dynamic linking: virtual machine has fixed program storage for
   library code (a ROM), and assembler makes jump references
   specifically for this program storage
@@ -276,3 +255,24 @@ That would be a very simple way of solving the static vs dynamic
 linking problem: just include the files you actually need.  Even the
 standard library would be fine and not require any additional work.
 Let's see how this would work.
+** DONE Do not request for more memory in registers
+The stack is a fixed size object allocated at the start of a program
+and inserted onto the VM.  The VM cannot request more memory for the
+stack if it runs out, but this also ensures a very strict upper bound
+on stack memory usage which can be profiled easily.  Furthermore, the
+code that interacts with the stack can use the strict sizing as an
+invariant to simplify implementation (e.g. pushing to the stack when
+the stack is full will trap the program).  Also the stack cannot be
+used to OOM attack the virtual machine.
+
+Registers are currently dynamic arrays.  Say 8 word registers are
+allocated at init time.  If a user requests a 9th word register,
+memory is requested from the operating system to increase register
+space.  This is unacceptable from both a profiling and an attack point
+of view; it would be trivial to write a program which forced the
+runtime to request ridiculous amounts of memory from the operating
+system (for example, by ~mov.word <very large number>~).
+
+Registers should not be infinite; a standardised size (with a compile
+time option to alter it) ensures the benefits stated above for the
+stack.