As some may have seen I posted a patch to gcc-patches that adds a way to embed GCC as a shared library, for Just-In-Time compilation, for use e.g. by bytecode interpreters: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html
I've gone ahead and created a git-only on the mirror as branch "dmalcolm/jit": http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/dmalcolm/jit and I've been committing patches there. I plan to post some of the patches for review against trunk (am bootstrapping/regtesting them as I write). An example of using it can be seen at: https://github.com/davidmalcolm/jittest/blob/master/README.rst Some questions for the GCC steering committee: * is this JIT work a good thing? (I think so, obviously, but can I go ahead and e.g. add it to the wiki under "Current Projects"?) * do you like the general approach? I'm choosing to deliberately hide as much as possible of GCC's insides, trying to hit the use-case of being able to add a JIT to an existing interpreted language whilst avoiding scope-creep. * it seems worthwhile to have a place to discuss the JIT work: both in terms of development *of* the branch, and for developers wishing to *use* the library in their own projects. I strongly feel that the only good APIs are those that are developed alongside *users* of those APIs (this forces one to smooth off the rough edges from the API). Hence is it reasonable to have a "j...@gcc.gnu.org" mailing list for this? * what would need to happen to get this into 4.9? or is this an unrealistic goal? * should I be posting my patches to "dmalcolm/jit" to the gcc-patches mailing list as I commit them? Also, should this be just a "jit" branch? (i.e. not under "dmalcolm/") Thanks Dave
