Why doesn't JUMP_IF_FALSE do POP_TOP ?

[John Machin]

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
optimisations.

> > 
> > 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.
if_false_push_false_then_jump

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.