From: Noah Lavine <noah.b.lavine@gmail.com>
To: guile-devel@gnu.org
Subject: Lightning Bindings
Date: Thu, 27 May 2010 17:03:48 -0400 [thread overview]
Message-ID: <AANLkTinTI38-V8uMypfedTN9vZ-HVRFihWbiXQSLJ2gV@mail.gmail.com> (raw)
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
next reply other threads:[~2010-05-27 21:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 21:03 Noah Lavine [this message]
2010-05-28 20:49 ` Lightning Bindings No Itisnt
2010-05-28 21:38 ` Noah Lavine
2010-05-29 20:09 ` Thien-Thi Nguyen
2010-06-01 14:57 ` Noah Lavine
2010-06-01 17:55 ` Ludovic Courtès
2010-06-02 20:47 ` Thien-Thi Nguyen
2010-05-29 21:39 ` Ludovic Courtès
2010-06-01 9:06 ` Andy Wingo
2010-06-01 14:55 ` Noah Lavine
2010-06-01 19:24 ` Andy Wingo
-- strict thread matches above, loose matches on Subject: below --
2010-05-31 22:49 Noah Lavine
2010-06-01 9:15 ` Andy Wingo
2010-06-01 18:02 ` Ludovic Courtès
2010-06-01 20:42 Noah Lavine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTinTI38-V8uMypfedTN9vZ-HVRFihWbiXQSLJ2gV@mail.gmail.com \
--to=noah.b.lavine@gmail.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).