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