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