Le 02/03/2016 20:21, Ben Coman a écrit :
On Wed, Mar 2, 2016 at 6:20 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 02/03/2016 11:07, Ben Coman a écrit :
Back to Dimitris' original question, I wonder that the potential speed benefit comes not so much from using "C", but from leveraging a large body of work on optimizing passes at the lower level. I found a tutorial [1] to produce a toy language "Kaleidoscope" that generates LLVM IR such that "by the end of the tutorial, weâll have written a bit less than 1000 lines of code. With this small amount of code, weâll have built up a very reasonable compiler for a non-trivial language including a hand-written lexer, parser, AST, as well as code generation support with a JIT compiler."
What is costly in the Pharo space is the fact that Kaleidoscope rely on the LLVM C++ infrastructure to generate the IR. And this linking to C++ code and classes is hard to do.
Are you referring only to FFI interfacing versus C++ name mangling, for which "the C bindings in include/llvm-c should help a lot, since most languages have strong support for interfacing with C.[A]" or something more?
No, just the fact that the IR is quite complex (have a look into the llvm IR reference), so you use a context and a builder (Builder.CreateFAdd) in the C++ code (and I think the Ocaml llvm module is probably large since it recreates the structure). The naming scheme of LLVM is quite complex and unobvious as well (the %0, %1, etc...) with strange rules biting you if you don't number the same way as LLVM does when you use its API. Thierry
[A] http://llvm.org/releases/3.1/docs/FAQ.html
cheers -ben