Neat! Have you looked into libjit? The only reason I bring it up is because it seems to be more popular than Lightning and already has some third-party language bindings.
On Thu, May 27, 2010 at 4:03 PM, Noah Lavine <noah.b.lav...@gmail.com> wrote: > Dear Guile Developers, > > After watching the discussion of native code generation on this list a > few weeks ago, I decided I'd like to help. I looked at several > possibilities, but it seemed like the easiest and most sure way of > making *something* work was writing bindings to GNU Lightning. > > I now have a start at working bindings for Lightning, which you can > see at http://github.com/noahl/guile-lightning. Currently it can only > use a few Lightning instructions, but I have enough to verify that it > generates executable code and that code interfaces with Guile. At this > point I could fairly easily go through the Lightning manual and add > more functions, command-by-command, until I had a complete interface > to the Lightning API. > > My thought was to do enough of the Lightning API that it could call C > functions, and then implement a compiler from Guile VM code to native > Lightning-generated code that just called a series of VM functions. > There wouldn't be any inlining or cool things like that, but it would > be a start. You could then add inlining support for individual VM > functions as it seemed important. At that point I would also want to > wrap the rest of the Lightning API, both so that inlined VM functions > could use it and so that other Guile programs could use Lightning like > any other module. > > However, I would like to ask two questions before I do that, to make > sure the result is ultimately useful. > - First, would you like Lightning bindings? As I said, I think it's > the fastest way to get some native code generation going, but I don't > think it'll ultimately be the best. (I can clean up and post my notes > on different code generation systems if you'd like them.) > - Second, what would a good interface to a native code generation > system be? (I'm assuming we'll want Lightning available as a regular > module in addition to using it to speed up the language.) My current > prototype just mimics the Lightning API, but it's not necessarily the > best way to do this. Is there a better way? > > Thank you > Noah Lavine > >