This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author doublep
Recipients
Date 2007-07-31.14:12:00
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.
History
Date User Action Args
2007-08-23 16:12:56adminlinkissue1764638 messages
2007-08-23 16:12:56admincreate