Matt Fowles wrote: [ thanks for your summary ]
Another summary can be found here: http://xrl.us/gban
... Discussions about specific solutions should and religion should have a seperate thread.
I'll put together some more WRT:
4) variable sized register frames
During the discussion of continuations I've posted this idea here: http://xrl.us/gbai
+ never have unused registers + no need for a register allocator
This is simplified. We'd need a register allocator for temporary variables. But it's true that all the register allocation troubles we now have with long-ranged variables would be gone as well as the speed problems with Evil Subs and the need for spilling.
+ could correspond directly to scratchpad - more complicated
Slightly but not much.
- no register reuse
No register reuse of registers persistent around a call, which is exactly the solution for the continuation problem. It's the same thing with setjmp(3)/longjmp(3). In the presence of continuations (longjmp()s) you can't reuse a register. Temporary registerers are of course reused as now.
- large architectural change
We now have Parrot 0.2.1 - what's the problem? Abandon a solution because we have to change internals is not the best idea.
- more custom allocation (can't pool register sets)
I've already proposed a scheme to allocate the register frames from 64KB chunks.
But there are still more arguments, why this solution is by far the best one. Please read the thread of my analysis of the fib benchmark: http://xrl.us/gbaj
This clearly shows that we can't keep the fixed-sized register frame in the long run. All the object getter and setter methods would suffer as badly as the plain function call from fib(). You might also try to run Ackermann(3, 9) if you've plenty of time ;-)
| Python is running the code on the stack. It's | touching only SP(0) and SP(1) mostly. | Register usage analysis of fib shows that it could run on Parrot with | just *one* persistent register per kind. leo
