Hi,
For my registervm project (fork of CPython using register-based
bytecode, instead of stack-based bytecode), I implemented a
Instruction.use_stack() method which just checks if the stack is
"used": read the stack, exchange values in the stack (like "ROT"
instruction), push or pop a value.
Instruction.use_stack():
http://hg.python.org/sandbox/registervm/file/ff24dfecc27d/Lib/registervm.py#...
The method uses a dummy heuristic, just because it was quick to
implement it, and it's enough for my use case.
To answer your question: yes, I would like a opcode_stack_effect() function.
registervm has its own disassembler which creates objects, rather than
just generating a text representation of the bytecode. I'm using
objects because I rewrite most instructions and I need more
information and functions:
* disassembler (raw bytes => list of instructions)
* assembler (list of instructions => raw bytes)
* format an instruction (human readable assembler)
* is_terminal(): last instruction of a block
* is_cond_jump(): the instruction is a conditional jump? hesitate to
move this disassembler to CPython directly. I'm not sure that it would
be useful, its API is maybe too specific to my registervm project.
* is_reg_used(), is_reg_replaced(), is_reg_modified(), etc.: checks on registers
* etc.
Would it be useful to have such high-level API in Python?
Victor
2013/7/3 Larry Hastings
I wrote my own assembler for Python bytecode called "Maynard". I had to statically compute the stack effects for each bytecode instruction by hand; what I did was copied and pasted opcode_stack_effect() (which is static) out of Python/compile.c and into my own driver program, then I probed it with test values to produce a table. I then coded up a function using that table, but hand-calculating the value sometimes as there are some opcodes whose stack effect varies based on the oparg.
It sure would be nice if this information was simply available to the Python interpreter; theoretically it can change between point releases. Would anybody mind if I added it somewhere? I'd probably just expose opcode_stack_effect to Python, then add all this other junk to the dis module and make it available there.
/arry
_______________________________________________ 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/victor.stinner%40gmail.com