Re: optimizations

Tim Peters (
Fri, 08 Apr 94 02:20:49 -0400

> [tim, being pessimistic]
> ...
> Caution: it may be the case that the [BUILD_TUPLE/UNPACK_TUPLE] pair
> has as a side-effect inverting the order of the top N stack entries; in
> which case just deleting the pair would be disastrous, and repairing
> that could be difficult at the byte-code level (but should be easy
> enough at codegen time).

Not pessimistic enough, though! It _does_ invert the order of the top N
stack entries, but perhaps not so easy to repair.


tuple1 = tuple2

the Reference Manual guarantees left-to-right evaluation of tuple2, and
left-to-right binding in tuple1, but leaves unspecified whether, e.g.,
_all_ sub-expressions in tuple1 have to be evaluated after _all_ sub-
expressions in tuple2 have been evaluated. So the behavior of the
following mess isn't wholly defined, but _most_ of it's defined:

j = 0
def out():
global j
j = j + 1
return j

def f():
a, i, a[i + out()] = [out()]*10, out(), out()
print i, a

That prints

2 [1, 1, 1, 1, 1, 1, 3, 1, 1, 1]

today (implying that everything on the RHS is evaluated before any part
of anything on the LHS is evaluated).

Evaluating the RHS left-to-right, and pushing the results on the stack as
you go, leaves them in the wrong order for left-to-right binding of
the LHS, and byte-code doesn't support an elementary (read dirt-cheap)
stack operation that can worm around that. But changing the evaluation
order on either the LHS or the RHS would change the visible semantics.

stinking-stack-based-virtual-machines<grin>-ly y'rs - tim

Tim Peters
not speaking for Kendall Square Research Corp