diff --git a/docs/source/programming.rst b/docs/source/programming.rst
index 4c4d6362a..6dbc64698 100644
--- a/docs/source/programming.rst
+++ b/docs/source/programming.rst
@@ -505,7 +505,6 @@ Subroutines are parts of the code that can be repeatedly invoked using a subrout
 Their definition, using the ``sub`` statement, includes the specification of the required parameters and return value.
 Subroutines can be defined in a Block, but also nested inside another subroutine. Everything is scoped accordingly.
 
-
 Calling a subroutine
 ^^^^^^^^^^^^^^^^^^^^
 
@@ -514,9 +513,11 @@ It is possible to not store the return value but the compiler
 will issue a warning then telling you the result values of a subroutine call are discarded.
 
 .. caution::
-    Note that *recursive* subroutine calls are not supported at this time.
+    Note that due to the way parameters are processed by the compiler,
+    subroutines are *non-reentrant*. This means you cannot create recursive calls.
     If you do need a recursive algorithm, you'll have to hand code it in embedded assembly for now,
     or rewrite it into an iterative algorithm.
+    Also, subroutines used in the main program should not be used from an IRQ handler.
 
 
 .. _builtinfunctions:
diff --git a/docs/source/todo.rst b/docs/source/todo.rst
index f2f1e8c62..2ea0f5705 100644
--- a/docs/source/todo.rst
+++ b/docs/source/todo.rst
@@ -31,6 +31,9 @@ Add more compiler optimizations to the existing ones.
 - on the final assembly source level
 - can the parameter passing to subroutines be optimized to avoid copying?
 
+- make sure user-defined blocks come BEFORE library blocks (this helps zeropage variable allocations)
+- subroutines with 1 or 2 byte args (or 1 word arg) should be converted to asm calling convention with the args in A/Y register
+
 
 Also some library routines and code patterns could perhaps be optimized further
 
@@ -48,10 +51,40 @@ Allocate a fixed word in ZP that is the TOS so we can operate on TOS directly
 without having to to index into the stack?
 
 
+More flexible (non-const) arrays?
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Currently, array literals can only be constants
+Allow for non-const arrays? Such as::
+
+    ubyte[16]  block1
+    ubyte[16]  block2
+    ubyte[16]  block3
+    ubyte[3] blocks = [block1, block2, block3]
+
+
+structs?
+^^^^^^^^
+
+A user defined struct type would be nice to group a bunch
+of values together (and use it multiple times). Something like::
+
+    struct Point {
+        ubyte   color
+        word[3] vec = [0,0,0]
+    }
+
+    Point p1
+    Point p2
+    Point p3
+
+    p1.color = 3
+    p1.vec[2] = 2
+
 
 Misc
 ^^^^
 
 - sqrt() should have integer implementation as well, instead of relying on float SQRT for all argument types
 - code generation for POW instruction
-- make sure user-defined blocks come BEFORE library blocks (this helps zeropage variable allocations)
+- are there any other missing instructions in the code generator?
+- implement %asmbinary