Re: Lightning Bindings

[No Itisnt]

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 <address@hidden> 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
>
>