Stacks, Joy, Oberon, C

Soren Renner — 2000-09-14 18:42:14

The "benchmark" of a few days ago, indicating that the "Toy" interpreter was twice as fast as Joy-C, is now obsolete. Erase it from history. Toy is being revised and should soon be slower. Why? Because the implementation was wrong . . . it could create deeply nested structures that crashed the Oberon stack when they were printed. Why? Because print() was recursive: 



TYPE someBox ...



PROCEDURE print;

BEGIN

     (** print contents of box  *)

     IF next # NIL THEN

	 next.print

     END

END print;	



Naturally the Oberon runtime has a restriction on stack recursion. So a deeply nested object cannot be printed. print() is not a Toy operator, but many of the ops (PROCEDURE op(VAR stack:BOX);) share the same defect. This became clear when I thought about Toy threads. I invented continuations, which was handy, because I had never understood them before. The mixing of Toy and Oberon recursion was the problem and Toy is now being rewritten without a stack, or rather, the stack and program are now one thing instead of two things. Removing recursion should slow the interpreter because Oberon recursion is faster than nonrecursive Toy -- here's what I mean: take "map". It was written with a loop in Oberon that took each item in one list, applied a program from another list to the item, and put the result in a third list. But the mapped program could of course contain another "map" or some other operator which forced another Oberon procedure call ... and so on. Instead, there should be one structure for a program, and one operation which applies to it repeatedly (rewriting).



So my QUESTION is: does Joy-in-C use the C stack or not?



"Under the name of Sanders"



sr