Why doesn't JUMP_IF_FALSE do POP_TOP ?
sjmachin at lexicon.net
Mon Jan 13 11:06:08 CET 2003
Paul Rubin <phr-n2002b at NOSPAMnightsong.com> wrote in message news:<7x8yxqxeav.fsf at ruckus.brouhaha.com>...
> Tim Peters <tim.one at comcast.net> writes:
> > > It seems like usually POP_TOP is the next byte code on either branch.
> > > Or is there a difficult case where the value is needed on the stack?
> > > It seems like the 99% case is getting the overhead (and also making the
> > > polling interval counter count unnecessary codes).
... and those pesky POP_TOPs get in the way of some useful
> > I've been asking that for years <wink>. The only reak answer is "it seemed
> > like a good idea at the time". Chained comparisons exploit it, but offhand
> > I don't recall anything else.
> Seems simple enough to add a new code that combines the two? That
> would avoid breaking old compiled code.
Could add more than one; below is the inventory of conditional jump
opcodes from a you've-never-heard-of-it language. All of the opcodes
pop the stack first and jump depending on the popped value.
For simple conditions: JF i.e. jump_if_false
For short-circuit AND (and Python's chained comparisons): JFF i.e.
For short-circuit OR: JTT i.e. if_true_push_true_then_jump
Also to allow for post-code-generation optimisations where there there
was a NOT involved, the inverses (JT, JTF, and JFT) were implemented.
More information about the Python-list