Yes, I tried, but I couldn't get it to build on my system for some reason, so I went with Lightning. I could try harder to get it to build if it seems like a good choice.
On Fri, May 28, 2010 at 4:49 PM, No Itisnt <theseaisinh...@gmail.com> wrote: > 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 >> >> >