Front page | perl.perl6.internals |
Postings from May 2001
> While RISC style opcodes have a certain pleasant simplicity to them, the > opcode overhead'll kill us. (If perl 5's anything to go by, and in this > case I think it might be) I don't understand what the opcode overhead you meant. It can not be worse than stack based opcode. > The size of the generated bytecode's likely not going to be directly an > issue in determining speed. (And we can't count on keep the locals > exclusively in the register set either, as otherwise string eval won't be > able to find them, and neither will the debugger) If we have 64 registers, I bet 99.99% of locals will fit into register set. For the debug information, we just need a hash to map my name to register id. This is needed even for stack based code. How to deal with optimization is a different story. However, it has nothing to do with the register based scheme itself. For example, an local variable is not used by any of the code, however an eval($s) may refer to it. So should optimizer eliminate the local? HongThread Previous | Thread Next