Frank J. Lhota wrote:
> Now imagine that generators saved their state data in the block regions,
> instead of on the C stack. That is, imagine that the expression !"ABC"
would
> allocate a block object that contains information indicating the last
value
> generated, along with a method for generating the next generated value.
If
> this scheme was implemented, would there be any need for the coswitch
> function?
Probably not, but I suspect that you'd see a performance impact.
I think this approach would require that every tem****ary value be placed
into these block objects instead of on the C stack - since very expression
is potentially a generator or need to be saved in case of a co-expression
switch. (To avoid doing this would take some *very* clever analysis to
determine when it's safe to leave values on the stack. For example,
in:
x := a*2 + f()
where do you compute and store the result of a*2? It would have to go
into the block unless you can determine that f() is neither a generator
nor contains a co-expression activation - and since the value of f() can
change dynamically, it seems effectively impossible to do so.
The 'C' stack is traditionally used for tem****ary values because [he
claims]:
a. allocating/deallocating storage for tem****ary values is very
efficient for 'traditional' operations (procedure calls and
non-generator expression evaluation
b. most machines provide very efficient instructions for accessing
values on the stack (relative addresses, etc.)
Switching to a block-based evaluation scheme may not be much worse (but
it would be at least a little worse) for (a) since deallocation would
fall out in the normal GC operation, but would almost certainly
be worse for (b) [he claims].
However, that still doesn't mean this shouldn't be looked at more!
Modern machines are so freaking fast that a little loss in performance
may be overwhelmed by a gain in functionality - and switching to a
block-based evaluation structure opens the doors to a number of
interesting ideas. You're no longer so closely tied to the traditional
hierarchical control flow. Parallel evaluation of co-expressions
becomes easier to implement, for example. Computing stack traces
would be an interesting exercise (but very doable as long as one
knows to look for cycles).
This would be a good topic to involve the Unicon mailing list in!
-Steve
--
Steve Wampler -- swampler@[EMAIL PROTECTED]
gods that smiled on your birth are now laughing out loud.


|