[ python-Feature Requests-1764638 ] add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP

[SourceForge.net]

Feature Requests item #1764638, was opened at 2007-07-31 17:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Pogonyshev (doublep)
Assigned to: Nobody/Anonymous (nobody)
Summary: add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP

Initial Comment:
In disassembled code of Python functions I often see stuff like this:

            421 JUMP_IF_FALSE           14 (to 438)
            424 POP_TOP

1178        ...
            435 JUMP_FORWARD             1 (to 439)
        >>  438 POP_TOP
        >>  439 END_FINALLY

Note how both branches of execution after JUMP_IF_FALSE do POP_TOP.  This causes the true-branch add JUMP_FORWARD, the only purpose of which is to bypass the POP_TOP command.

I propose adding two new bytecodes, JUMP_IF_FALSE_AND_POP and JUMP_IF_TRUE_AND_POP.  Their semantics would be the same as that of existing JUMP_IF_FALSE/JUMP_IF_TRUE except the commands would also pop the stack once, after checking whether to jump.  This would simplify the above code to just

            421 JUMP_IF_FALSE_AND_POP           14 (to 438)

1178        ...
        >>  438 END_FINALLY

This shortens bytecode by 5 bytes and both execution branches, by 1 and 2 commands correspondingly.

I'm willing to create a patch, if this sounds like a worthwile improvement.  Maybe it is better to skip 2.6 and target it for 3000 instead.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470