From a24196f236bd3d5cac6a8ea52a8510959f36cf9b Mon Sep 17 00:00:00 2001 From: Aryadev Chavali Date: Mon, 24 Jun 2024 17:03:19 +0100 Subject: [PATCH] Fix up some TODOs --- todo.org | 70 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/todo.org b/todo.org index e94d6eb..dc9fd37 100644 --- a/todo.org +++ b/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 ~). - -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 ~). + +Registers should not be infinite; a standardised size (with a compile +time option to alter it) ensures the benefits stated above for the +stack.