On 5/31/10 4:50 PM, Patrick R. Michaud wrote:
The above proposal looks to me as though it is reducing the number of opcodes at the expense of increasing the runtime opcode dispatches and the size of the resulting bytecode. That feels very much like a false optimization to me. (Again, I may be totally misreading what is proposed or missing some key component in all of this.)
[...]
It may also be worth noting that PCT currently attempts to bias towards the constant-form of opcodes wherever it can, under the theory that this leads to faster/smaller code. (However, I can come up with quite a few common cases where such optimization turns out to be not optimal, so some pieces there need to be rethought as well.)
The general rule is *compiler writers shouldn't be thinking about that low level of optimizations*. Once we get into more advanced forms of optimization (which we have to do in the next few years), all bets are off for the low-level details of the opcode. All we will guarantee is that you can call the opcode with a specified set of signatures (constants, registers, pmcs) and the opcode will store a result for a specified set of return signatures (registers, pmcs).
If an opcode accepts a constant argument, but the first thing it does is box that constant and passes it off to another operation, it really doesn't matter if it does the boxing as part of the opcode dispatch or as a separate operation within the opcode. Furthermore, if the opcode accepts a register/pmc argument, but never modifies it, it should be free to treat that argument as a constant throughout the body of the opcode. Again, it really doesn't matter if the unboxing happens as part of the opcode dispatch, or within the body of the opcode.
The author of the opcode, the JIT compiler, or the low-level optimization pass should decide if constants/i-n-s-registers/pmcs are more common argument types, whether to perform boxing/unboxing, or whether to provide special forms for specific types of arguments as an optimization.
Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
