[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lightning Bindings
Re: Lightning Bindings
Fri, 28 May 2010 17:38:06 -0400
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 <address@hidden> wrote:
> 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