summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSøren Sandmann Pedersen <ssp@redhat.com>2014-01-31 08:07:54 -0500
committerSøren Sandmann Pedersen <ssp@redhat.com>2014-01-31 08:07:54 -0500
commitc20a9086f607cfcc699958d3aaeb40e8662f06f3 (patch)
treee07098259db83e11b17de64d43fa486507389c40
parent818bd4687c9c14e5ad9bdc3b1bf2572f26943929 (diff)
TODO: expressions with gotos in them
-rw-r--r--TODO60
1 files changed, 60 insertions, 0 deletions
diff --git a/TODO b/TODO
index 05d4933..79e97aa 100644
--- a/TODO
+++ b/TODO
@@ -1,3 +1,63 @@
+* Expressions with goto in them
+
+ A simple example is
+
+ F() { goto blah; }
+
+ print 7 + F();
+
+ @blah:;
+
+ where we jump to blah, leaving 7 on the stack.
+
+ There is another case, captured in popbug3.nl, where we keep
+ returning from the same function. Each time the result is added to
+ something popped from the stack. This results in a stack underflow.
+
+ Part of the solution will have to be to keep a reference to the
+ expression stack. This of course implies that popping the stack can't
+ actually remove the stack entries.
+
+ A different problem is if the stack references a variable. Should
+ that variable be evaluated every time? My intuition says no. Consider
+
+ ret: label = null;
+
+ x = 0;
+
+ F() { ret = back; @back: return 10; }
+
+ print x + F();
+
+ x++;
+
+ if (x < 100)
+ goto ret;
+
+ if you do this, F() will return 100 times, but the evaluation of
+ the 'x' in 'x + F()' will be skipped every time.
+
+ It seems the expression stack will have to become a tree with heap
+ allocated entries. An environment will then contain a pointer to a
+ node of this tree.
+
+ What does this mean for the bytecode? For example, an ADD operation
+ should now take the two values on top of the stack and create a new
+ value whose 'next' pointer is the same as the next pointer of the
+ second value on the stack.
+
+ Should this be done at the bytecode level? It may be that there
+ should be separate 'dynamic' versions of all the stack ops. These
+ might operate on a leaf pointer on the stack.
+
+ In the case where we can detect that an expression doesn't escape,
+ the array based stack could then be used. Is detection as simple as
+ there being no function calls in the expression? And no
+ statement-expressions, presumably.
+
+ This will have to be considered an optimization.
+
+
- Short-term tasks:
- Test suite