Two questions about jump opcodes
Hi, I'm attempting some bytecode tweaks (see http://bugs.python.org/issue2459) and I've got two questions about jump instructions: - Why are there both relative and absolute jump instructions? The traditional rationale for relative jumps (apart from position-independent code) is to allow for shorter operand sizes; but Python opcodes all have the same operand size (and 16 bits is more than enough to address most bytecode arrays). - Why are relative jumps unsigned? This means they can only jump forward, and as soon as you want to jump backward you have to switch to an absolute jump... (in that regard, I don't understand what JUMP_FORWARD can possibly bring over JUMP_ABSOLUTE) Thanks for your kind answers Antoine.
At 10:43 PM 3/22/2008 +0000, Antoine Pitrou wrote:
- Why are there both relative and absolute jump instructions? The traditional rationale for relative jumps (apart from position-independent code) is to allow for shorter operand sizes; but Python opcodes all have the same operand size
Actually they don't. They can have 32-bit arguments, with the EXTENDED_ARG opcode. EXTENDED_ARG loads the high 16 bits of the argument in the opcode that immediately follows.
(and 16 bits is more than enough to address most bytecode arrays).
Ah, but not *all* bytecode arrays. Apparently some (automatically generated) code at LucasFilm (if memory serves) exceeded some of the 16-bit limits for bytecode, so the EXTENDED_ARG opcode was added to fix this.
- Why are relative jumps unsigned? This means they can only jump forward, and as soon as you want to jump backward you have to switch to an absolute jump...
With a backward jump, you already know the exact offset, so you know if you need a 16-bit or 32-bit operand.
(in that regard, I don't understand what JUMP_FORWARD can possibly bring over JUMP_ABSOLUTE)
It means you don't have to guess whether your jump target is going to cross the 64K boundary, thereby requiring you to have used a 32-bit operand. Of course, it does limit your forward jumping to skipping no more than a 64K block, but apparently nobody has exceeded that limit yet. :) Merely having 64K of total bytecode is presumably an easier limit to reach than *jumping over* 64K worth of bytecode. :) In truth, I don't know if that's really the reason why things were originally set up this way, but these are certainly among the reasons thing will probably stay this way. :)
Antoine> - Why are there both relative and absolute jump instructions? The best place to search for the reasons behind this is Python/compile.c. (JUMP_ABSOLUTE can jump backwards.) There have been lots and lots of changes to the Python virtual machine the past few years. When trying to understand the basic concepts it might be best to check out a very old version of the code from Subversion (1.5.2, 2.0, 2.1, etc). Those versions have many fewer optimizations, so it's likely that compile.c and ceval.c will be more readable. (My full understanding of the virtual machine probably ended with 1.5.2.) That should give you a basic understanding of how things work without the obfuscation added by the many optimizations. You can then move to more recent versions and more easily see what's going on, even in the face of all the optimizations. Antoine> (in that regard, I don't understand what JUMP_FORWARD can Antoine> possibly bring over JUMP_ABSOLUTE) Well, you can't chain jumps together with the latter. If, for some reason, you needed to jump forward more than 16kbytes you could accomplish that with multiple JUMP_FORWARD opcodes. Skip
Wow, thanks to both of you (Phillip & Skip) for the fast answers. Just in case anyone has time to spare, I have more pesky questions (and a working patch :-)) in the aforementioned bug entry (http://bugs.python.org/issue2459). Regards Antoine.
This across the board speedup of the python byte code looks promising! I'm not familiar enough with that part of the code to review it but here's a big +1 to make sure someone else takes a look. On Sat, Mar 22, 2008 at 4:07 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Wow, thanks to both of you (Phillip & Skip) for the fast answers. Just in case anyone has time to spare, I have more pesky questions (and a working patch :-)) in the aforementioned bug entry (http://bugs.python.org/issue2459).
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
participants (4)
-
Antoine Pitrou -
Gregory P. Smith -
Phillip J. Eby -
skip＠pobox.com