libjit
Robert Spier
Is there anything that can be learned/reused from libjit?
http://www.southern-storm.com.au/libjit.html
-R
Leopold Toetsch
> 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. It looks rather mono-specific and is (of course)
running a stack machine.
> -R
leo
Rhys Weatherley
> 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.
Leopold Toetsch
> On Tuesday 26 October 2004 07:55 pm, Leopold Toetsch wrote:
>>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.
Sorry, yes of course. I'm always mixing these two projects.
> 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.
Yep. Well, a low-level libjit-like library would be interesting, though.
One that just translates three-address statements to machine language.
> One of the back ends is an interpreted stack machine instruction set.
Yes, I saw that.
> 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.
Of course. VMs are written for specific languages, they tend to become
very specific for one language and probably hard to use for a different
one. Parrot should be able to run a lot of dynamic languages ...
> Cheers,
>
> Rhys.
leo