[Python-Dev] Two questions about jump opcodes

[Phillip J. Eby]

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.  :)