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 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 <chromatic at 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
>>
>



-- 
http://code.google.com/p/libjit-linear-scan-register-allocator/