This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text] an embeddable JIT-compilation library based on GCC

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:

I've gone ahead and created a git-only on the mirror as branch
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:

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

  Hence is it reasonable to have a "" mailing list for

* 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/")


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]