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.
|
