[LLVMdev] accessing a bitcode library exported from C++ using the JIT

[Samuel Crow]

Hello OvermindDL1,

We are implementing an extensible language.  That's one where you can add commands and constructs to the language without having to recompile the parser.  We want compilation of the parser in order to "freeze" it but only as an option.  One goal is to eventually get the macro functions of our language to the point where they are equivalent to the template functions of C++ so we can make a self-hosting langauge.

Also, all of the action nodes in our example PEG parser are written in LLVM Assembly rather than only C++ (although they call functions from a C++ library) so I doubt it would work in Spirit2.1 without writing a syntax converter.  The syntax converter may come in time but it's only optional.  If you're really interested in a partially finished example parser, it is at http://mattathias.cvs.sourceforge.net/viewvc/mattathias/mattathias/modules/front_ends/Amos/ .  It contains a PEG parser file and the source to a C++ library included in that PEG file.


Thanks for your interest,

--Sam


----- Original Message ----
> From: OvermindDL1 <overminddl1 at gmail.com>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Monday, August 31, 2009 8:47:05 PM
> Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using the JIT
> 
> On Mon, Aug 31, 2009 at 6:23 PM, Samuel Crowwrote:
> > If you're wondering why we're doing an interpreted PEG parser generator rather 
> than Boost Spirit 2.x, it's because we need it to be easier to debug the parser. 
>  Once the parser is debugged it can be fed into a compiled parser generator and 
> "frozen" into stand-alone parser code.
> 
> You do know that Spirit2.1 has very nice debugging facilities,
> everything from error handlers so you can handle parsing failures to
> getting detailed info reports on the entire processing process (of
> which you can do something like dump it to cout or something and you
> get this nice tree of everything that is tried, what passes, what
> fails, etc...).  It is exceedingly detailed, so I am not sure what
> your homegrown one would have over it, if you have an example then I
> could add that functionality to Boost.Spirit2.1.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev