added thoughts on register allocation

TODO.md

@@ -17,3 +17,15 @@
   - a method that offers up a lease maybe has a return type completely inherited from its body (doesn't know N shape, other than that the register should participate somewhere)
 - maybe the AXY registers don't offer up leases and are always consumed in predictable, prepackaged ways
 - there needs to be another abstraction. just because reads and writes are tracked, doesn't mean they tie to exactly single addresses (think of a mechanism with many independent switches, all producing separate write actions)
+- automatic address assignment; if you stack them in a list, you can at "compile" time just assign registers from 0 to n
+  - have an easy combinator to switch between byte and word length
+  - and another combinator to switch between zero and global (maybe global is the default and zero is opt-in)
+- stack register assignment
+  - helper functions like multiplication (?) probably need a temp working area
+  - if always used like a well bounded resource, maybe you can keep reusing this temp area with different functions
+  - but if some one subroutine or "context" uses a function twice (e.g. 3 * 4 * 5) then the stack depth for that context is at least two now, which can be known at interpretation time by going through the call graph
+    - imagine the multiplier operation providing context/a lease and every operation on that lease actually pushes onto a stack
+      - 99% of the time the stack size would just be one but it could be for nested calls something else
+      - and then very late into register assignment (above) it would occupy N registers
+  - what if you model all functions using the same "bounce" area and then just use this as the canonical way to calculate stack depth
+    - this would maybe be "optimal" register allocation?