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
