On Tuesday 26 October 2004 07:55 pm, Leopold Toetsch wrote: > Robert Spier wrote: > > Is there anything that can be learned/reused from libjit? > > > > http://www.southern-storm.com.au/libjit.html > > Thanks for the link. But I think, while the idea is quite nice, it's not > really useful for us.
Probably true. Parrot is far enough along that changing fundamentals like this wouldn't be wise. > It looks rather mono-specific and is (of course) running a stack machine. There is another .NET implementation besides Mono, you know. Libjit is an off-shoot of the DotGNU Portable.NET project. Libjit internally uses three-address statements, similar to IMCC, to express the internal representation. Then the usual three-address optimizations, register allocation, and code generation is performed. One of the back ends is an interpreted stack machine instruction set. The interpreter is used purely for platforms that currently lack a CPU-specific native back end. It wouldn't be impossible to add a register-based interpreter instead, except that I prefer simplicitly over silly flamewars about which is faster: both suck at different things. There's little advantage in creating an ultra-fast interpreter for something like libjit: just write a native CPU back end! And existing VM's (of the Java and C# variety that this is targetted at) typically already have fast interpreters of their own. Libjit is also deliberately "just a JIT". Runtime libraries, object layout, garbage collection, on-disk bytecode representations, etc, are not dealt with. The aforementioned VM's already have all that. Hooks are present, but libjit mostly keeps to "mechanism, not policy" on these issues. From what I can see, if I was writing a VM from scratch, Parrot would be useful because I can design the VM around Parrot's idiosyncrasies from day 1. But if I'm retrofitting a JIT into an existing VM, I think Parrot would be more trouble than it is worth. But that's just me. There's plenty of room for both approaches. Time will tell. Cheers, Rhys.
