> 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?

Hong

Reply via email to