Michael Hudson wrote: >... > > Well, you'd have to have RETURN_VAR *as well* as RETURN_VALUE, or in > code like > > return a + b > > you'd have to create a temporary variable and store to it. > > We have a limit of 256 opcodes... First, I don't see anything wrong with temporary variables...you need to keep track of how many you use I suppose, so the compiler needs to be a little bit smarter. Second, some opcodes seem wasted to my naive eyes. e.g. PRINT_NEWLINE or all of the in-place variants of mathematical operators. Third, you yourself came up with a hack that would allow the same opcode to work on variables or the stack using "-1" as the variable index. >>Similarly, what if BINARY_ADD could work directly on constants and >>variables? I see the virtue of using the stack for objects that do not >>otherwise have a name. But if a value is in a contant or variable, why >>not refer to it by its position in co_consts or co_varnames. > > How would you implement this? Give BINARY_ADD two arguments > (something no bytecode has now, btw) and treat '-1' as 'pop from the > stack'? This sounds obfuscatory. If there is anywhere in the Python implementation where you trade some "readability" for some performance (and surely there are!) then wouldn't the bytecode be the place? I mean bytecodes are *byte* *codes*. They aren't tuples of pointers to nice pretty objects. They are a list of bytes that are Python's equivalent to assembly language. >>And as long as we are talking about referring to things more directly, >>wouldn't it be possible to refer to constants by pointer rather than >>indirecting through the index? You'd have to fix up pointers when you >>first loaded the code but only once per function. > > Could do. Opcode arguments are only 16 bits though, unless you use > the EXTENDED_ARG thingy, and then they're only 32 bits: what about 64 > bit platforms? You would have to extend the bytecode format. > Python's VM is currently a stack machine. There are arguments for > making it a register machine, but if we want to do that, lets go the > whole hog and not have some kind of half-assed hybrid. I'm not really talking about a register machine either. I don't understand why you would want to copy values from a heap in "main memory" into a register *still in main memory* to have the bytecodes operate on them to store to a register and then back to main memory. Perhaps we take the CPU analogy too far. Or perhaps there is something deep I misunderstand. Paul Prescod
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4