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 <[email protected]>: > > > 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 <[email protected]> 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/ > -- http://code.google.com/p/libjit-linear-scan-register-allocator/ _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
