Dan Sugalski <[EMAIL PROTECTED]> wrote:
If you want to go back to a frame pointer style of register stack access, that's doable, but that's the way it was in the beginning and the performance penalties in normal code outweighed the savings in stack pushes.
JITted memory access through the frame pointer is as fast as with absolute memory addresses. The same is likely true for gcc/CGP core, when we force the frame pointer being a CPU register.
I think you'll find that's not the case. And it's certainly not the case on non-x86 platforms. (I'm also not sure it's true on the x86-64 systems)
> If you want to try it again to see if things are different I don'tcare, so long as the semantics expressed to the bytecode programs don't change. It will invalidate all the current JIT code on all the platforms so it's a not-insignificant thing to do.
That's the problem, yes.
... I also don't think we've sufficient real code to judge performance, so I think it's a bit premature to worry about it.
This is of course true, the more for changing it in the first place :)
No, changing it made good sense at the time, and it *still* makes good sense. The base cores and the JIT on all platforms got a good boost because of it.
What about issues with JIT and prederefed cores and multi-threading: currently we need to "recompile" all bytecode per thread.
What about it? Threads or not, the single-threaded case is going to be the common case for parrot, and it's mildly faster in general. Emitting position-independent code's a transparent option if we want, and I'm not inclined to change the architecture because of it.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
