And because of a message that came up very recently, I infer that leo's
solution involves a variable-sized register frame.
This sounds like a much better solution than the one I've just proposed.
No saving/restoring, the register frame size is known at compile time
(so the double-indirection can be reduced to single), JIT still works.
So, scrap my proposal. Seriously consider his. My comments about "this
is a real problem and needs a real solution" still hold.
Luke
Luke Palmer writes:
> I looked through google groups and couldn't find leo's solution
> ("putting lexicals in registers", and I can't figure out what that
> means; couldn't you have a loop counter that isn't a lexical?).
>
> I think we all agree that this is a major problem, and that to ignore it
> would be a fatal mistake in Parrot's support of continuations. And
> parrot not supporting continuations means parrot not supporting
> coroutines. And that means parrot not supporting Perl 6 :-/
>
> We would like a solution that allows optimization, keeps JIT around, and
> behaves correctly. The main problem with "Dan's solution" (which I also
> couldn't find, but I'm inferring by talk about it) is that it restores
> things values when they may have already changed.
>
> So--here's the naive proposal. Naive because I'm not very good at
> foreseeing performance issues, etc. Keep in mind that this is a
> major architecture change (which we're not doing, right?), but can be
> made opaque with proper support from IMCC.
>
> No more value semantics.
>
> That's it. All values on the bytecode level are pointers. I's are
> pointers to ints (that's still a win since you don't need to keep going
> through a vtable), etc. P's are just as they used to be.
>
> Then to use an int, you have to allocate it first. Perhaps this can be
> made efficient with a specialized small-object pool attached onto the
> register frame for cache locality (which I don't really understand).
>
> Anyway, I'm expecting you smart guys to shoot this down. But
> something's got to be done about this problem. Proposals have to
> happen.
>
> Luke
>
