On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote: > At 06:25 PM 7/31/2002 +0200, Jerome Vouillon wrote: > >Closures > > > > A subroutine must have access to the scratchpads of all the > > englobing blocks. As the scratchpads are linked, it is sufficient > > to add a pointer to the immediately englobing scratchpads to the > > closure (Sub class). > > And they need to be COW, as closures have access to their > own copies of lexicals. I asked Jonathan to reuse the stack code > I had already written because it was using the same semantics > with COW as control and user stacks.
I'm confused here. In Jonathan's code, the stack is COW, not the scratchpads. If instead of using stacks you make each scratchpad contains a pointer to its parent, there is no need to copy anything: several scratchpads can then share the same parent. By the way, I don't understand how you intend to implement subroutine invocation. Are you going to push the caller scratchpad stack on a stack and replace it by (a copy of) the callee scratchpad stack? > We chose to implement > the access as ops, and you prefer using a PMC Array directly. I can > at least see one advantage to the explicit ops: they don't require > a register to use them in the general case. Adding special opcodes has a cost: they then need to be implemented for all architectures supported by the JIT compiler. But I'm especially frightened by opcodes such as new_pad. The Perl compiler may well be able to perform more optimizations if it does not use this opcode but rather generate specialized code. (And the JIT compiler may then be able to generate some inlined assembly code instead of a call to a generic C function.) So, I would feel more comfortable trying to reuse existing opcodes for the moment, especially as I don't think we have a clear view of the "right" way to implement lexical variables yet. It will still be possible to add new opcodes to improve performances when we have a working compiler to benchmark them. -- Jerome
