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