well, i imagined the simple way, as to let the pike compiler produce not pike byte code for execution in the pike interpreter but generate CIL instead.
So I gathered. If we're going to go through the trouble of adapting the pike core to a third party VM, we should consider well established ones like the Java VM. Maybe I've missed something - would it somehow be considerably easier to replace the Pike VM with CIL instead of JVM?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-17 22:09: Subject: pike and CIL/mono (was Re: source encryption)
On Sat, 2003-05-17 at 21:15, Martin Stjernholm wrote:
That could be interesting. How hard it'd be depends on how well its runtime matches pike behavior.
huh. i have no idea of the pike internals :-) though i guess it will not be very 'compatible'.
could someone please post a overview how pike vm/interpreter/code generator works?
from the mono site:
<quote uri="http://www.go-mono.com/runtime.html"> The JIT engine uses a code-generator generator approach for compilation. Given the properties of CIL byte codes, we can take full advantage of a real instruction selector for our code generator.
The JIT engine implements a number of optimizations:
Opcode cost estimates (our architecture allows us to generate different code paths depending on the target CPU dynamically). Inlining. Constant folding.
Although compilers typically do constant folding, the combination of inlining with constant folding gives some very good results.
Linear scan register allocation. In the past, register allocation was our achilles heel, but now we have left this problem behind.
</quote>
How does it compare to the Java VM? That has been around longer and should have some good compilers by now.
well, i imagined the simple way, as to let the pike compiler produce not pike byte code for execution in the pike interpreter but generate CIL instead.
also, the compiler is not the weak point i think, but the runtime engine.
/ karl
/ Brevbäraren