Re: Call for Mentors - "A prototype LLVM JIT runcore for Parrot" (gsoc). How about libJIT? See http://code.google.com/p/libjit-linear-scan-register-allocator/ <\eom>

[Kirill Kononenko]

Hi

How about using libJIT instead of LLVM JIT ? See:
http://code.google.com/p/libjit-linear-scan-register-allocator/ for
how much libJIT is better than LLVM.

I am ready to mentor and help with this.

Thanks,
Kirill

--
http://code.google.com/p/libjit-linear-scan-register-allocator/
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[chromatic]

On Thursday 16 April 2009 23:51:48 Kirill Kononenko wrote:

> How about using libJIT instead of LLVM JIT ? See:
> http://code.google.com/p/libjit-linear-scan-register-allocator/ for
> how much libJIT is better than LLVM.

I wouldn't say "better", but different. libJIT has some advantages (just a
JIT, arguably better C bindings, more standalone, perhaps less JIT startup
time, closer to our existing JIT but more cross-platform) and some
disadvantages (no clang to get some JIT for free, fewer developers).

Ultimately I think the libJIT approach will be better for Parrot than the
clang approach, though there's no reason we couldn't use only the LLVM JIT
portion and achieve the same thing.

With that all said, I'd like to see experiments with both approaches.

-- c
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Andrew Whitworth]

libJIT looks pretty interesting, I hadn't heard about it until now.
Judging from the few paragraphs I've been able to read today it looks
like it might be a little-bit focused towards .NET CLI, which isn't
going to be a win for us if we have to translate PBC to CLI before
executing the JIT. I think having alternatives is a good thing in
general, and if we had a good pluggable JIT interface in Parrot, we
could swap cores out with relative ease.That said, having any unifed
JIT core is going to be better then the home-brewed platform-dependent
method we are using right now.

Kirill: How much developer effort would it take to implement a
libJIT-based backend for Parrot, in your estimation? I doubt it's
going to be a GSOC project this year since we're already past the
application deadline.

--Andrew Whitworth

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Kirill Kononenko]

Hi Andrew,

Thank you a lot for your reply.

The focusing on CLI is rather of my project the
libjit-linear-scan-register-allocator. LibJIT has a .NET background
because we started it for our DotGNU Portable.NET JIT. I try to find
how we could make libJIT better for people. We have very limited
resources at this time. But we rather try to do the thing right from
first try. So limited number of people is not that big issue, in this
case - quality is more important, i think.

> libJIT looks pretty interesting, I hadn't heard about it until now.
> Judging from the few paragraphs I've been able to read today it looks
> like it might be a little-bit focused towards .NET CLI, which isn't
> going to be a win for us if we have to translate PBC to CLI before
> executing the JIT. I think having alternatives is a good thing in
> general, and if we had a good pluggable JIT interface in Parrot, we
> could swap cores out with relative ease.That said, having any unifed
> JIT core is going to be better then the home-brewed platform-dependent
> method we are using right now.
>
> Kirill: How much developer effort would it take to implement a
> libJIT-based backend for Parrot, in your estimation? I doubt it's
> going to be a GSOC project this year since we're already past the
> application deadline.

This kind of development is very incremental. I guess 2-3 months of 8
hours work, to make most of the core work. Then might be another 2-3
months of 8 hours work to test and fix minor issues. But it is much
easier than LLVM imo.

Thanks,
Kirill

>
> --Andrew Whitworth
>
> On Fri, Apr 17, 2009 at 1:59 PM, chromatic <chro...@wgz.org> wrote:
>> On Thursday 16 April 2009 23:51:48 Kirill Kononenko wrote:
>>
>>> How about using libJIT instead of LLVM JIT ? See:
>>> http://code.google.com/p/libjit-linear-scan-register-allocator/ for
>>> how much libJIT is better than LLVM.
>>
>> I wouldn't say "better", but different.  libJIT has some advantages (just a
>> JIT, arguably better C bindings, more standalone, perhaps less JIT startup
>> time, closer to our existing JIT but more cross-platform) and some
>> disadvantages (no clang to get some JIT for free, fewer developers).
>>
>> Ultimately I think the libJIT approach will be better for Parrot than the
>> clang approach, though there's no reason we couldn't use only the LLVM JIT
>> portion and achieve the same thing.
>>
>> With that all said, I'd like to see experiments with both approaches.
>>
>> -- c
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>

--

[Kirill Kononenko]

Hi Andrew,

I want to clarify one thing, that libJIT does not emit CLI
instructions. But we use libJIT to generate machine code from CLI in
DotGNU Portable.NET JIT. There is a some information about how libJIT
works here:

http://www.gnu.org/software/dotgnu/libjit-doc/libjit_1.html
http://en.wikipedia.org/wiki/LibJIT

There might be two apporachs to support libJIT in Parrot. The first
one, is to extend Parrot to make libJIT functionally available for
JITing with a wraper around Parrot. The second one is add another
parser or engine in Parrot for generation of machine code.

The first approach might be very easy to implement maybe 1-2 weeks.
The second one is 2 months of quiet relaxed work.

Thank you for your reply again. Let continue sharing of ideas on how
Parrot and libJIT may cooperate.

Thanks,
Kirill

2009/4/17 Kirill Kononenko <kirill.k...@gmail.com>: