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 <[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://lists.parrot.org/mailman/listinfo/parrot-dev
