[Python-Dev] Removing the 16 bit arg limit (original) (raw)
Vladimir Marangozov Vladimir.Marangozov@inrialpes.fr
Fri, 4 Aug 2000 01:27:39 +0200 (CEST)
- Previous message: [Python-Dev] tests for standard library modules
- Next message: [Python-Dev] Library pragma in PC/config.h
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I've looked at this and the best compromise solution I ended up with (before Py3K) is sketched here:
opcode.h: #define EXTENDED_ARG 135 /* 16 higher bits of the next opcode arg */
ceval.c: case EXTENDED_ARG: do { oparg <<= 16; op = NEXTOP(); oparg += NEXTARG(); } while (op == EXTENDED_ARG); goto dispatch_opcode;
compile.c: static void com_addoparg(struct compiling *c, int op, int arg) { if (arg < 0) { com_error(c, PyExc_SystemError, "com_addoparg: argument out of range"); } if (op == SET_LINENO) { com_set_lineno(c, arg); if (Py_OptimizeFlag) return; } do { int arg2 = arg & 0xffff; arg -= arg2; if (arg > 0) com_addbyte(c, EXTENDED_ARG); else com_addbyte(c, op); com_addint(c, arg2); } while (arg > 0); }
But this is only difficulty level 0.
Difficulty level 1 is the jumps and their forward refs & backpatching in compile.c.
There's no tricky solution to this (due to the absolute jumps). The only reasonable, long-term useful solution I can think of is to build a table of all anchors (delimiting the basic blocks of the code), then make a final pass over the serialized basic blocks and update the anchors (with or without EXTENDED_ARG jumps depending on the need).
However, I won't even think about it anymore whithout BDFL & Tim's approval and strong encouragement .
-- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
- Previous message: [Python-Dev] tests for standard library modules
- Next message: [Python-Dev] Library pragma in PC/config.h
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]