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. :) _______________________________________________ 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/archive%40mail-archive.com