At 06:25 PM 7/31/2002 +0200, Jerome Vouillon wrote:
>Scratchpads
>
>   We need to allocate an area in the heap for each lexical variable.
>   Instead of allocating this area one variable at a time, we can
>   allocate a single "scratchpad" value for all variables of a block:
>   this is more efficient.
>
>   The compiler can keep track of the index of the variables in the
>   scratchpad.  So, the scratchpad can be implemented as an array of
>   PMCs. (We will probably need some faster opcodes to access the
>   array: there is no need to perform a method call, nor to do any
>   bound checking.)

That is exactly what we are doing. However, the scratchpads themselves
are kept in a data structure, currently a stack, so discarding one
scratchpad activates the previous.

>MY
>
>   To implement MY, we need to be able to access to a variable by its
>   name.  For this, the compiler can generate statically a hash mapping
>   the variable name to its index in the scratchpad.  Then,
>   MY{"foo"} will look up the index of the variable "foo" in the
>   hash and use the index to get the variable PMC in the scratchpad.

I think this is the plan.

>   To access the scratchpad of an outer block, we need a way to move
>   from a scratchpad to its parent scratchpad.  This is trivial if we

Currently it is as a linked-list.

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

>Conclusion
>
>   It seems to me that to implement lexical variables, we only need to
>   implement the set_pmc method and to extend the Sub class so that it
>   contains both a code pointer and a scratchpad.

I agree with you. It can be done without special ops that we just added.
I see no reason why we can't add an op that allows you to get the
scratchpad into a Px reg and use it just as a Hash or Array. I expect
we might want to.

>   In particular, we don't need any special support for scratchpads, at
>   least for the moment.
>
>   What do you think?

I think you have the same idea that we do. 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.

-Melvin


Reply via email to