unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Noah Lavine <noah.b.lavine@gmail.com>
Cc: guile-devel@gnu.org
Subject: Re: Lightning Bindings
Date: Tue, 01 Jun 2010 11:06:15 +0200	[thread overview]
Message-ID: <m3d3wbqfzs.fsf@pobox.com> (raw)
In-Reply-To: <AANLkTinTI38-V8uMypfedTN9vZ-HVRFihWbiXQSLJ2gV@mail.gmail.com> (Noah Lavine's message of "Thu, 27 May 2010 17:03:48 -0400")

Hi Noah,

On Thu 27 May 2010 23:03, Noah Lavine <noah.b.lavine@gmail.com> writes:

> I now have a start at working bindings for Lightning, which you can
> see at http://github.com/noahl/guile-lightning.

Fascinating! Congrats on getting through the foreign function docs; a
high-level interface is really necessary there... But very cool to see
that you were able to get something working with so little code!

>    - 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?

Second question first :) I collected my general thoughts on native code
compilation here:

  http://thread.gmane.org/gmane.lisp.guile.devel/10234

I feel quite strongly that the calling convention for native code should
be the same as that of bytecode, and that it should use the same stack.
This way we don't have to maintain separate stack walkers or debuggers
or the like. Also this way we get proper tail calls and multiple value
handling as well.

I tend to think that Ludovic's proposal, or something like it, is the
most practical means to get a portable JIT compiler going; though I
don't really know.

In the end though Guile needs to be generating native code
ahead-of-time, I think. Doing that portably is hard; we'll need to
leverage some other project. I think that project should be GCC. I was
talking to Dodji Seketeli the other day, a GCC dev, and he says that GCC
maintainers are willing to allow other programs to use it for code
generation, but they don't know yet what abstractions they need to
provide.

So first we should probably implement a native code compiler directly
ourselves, for one architecture, and see how that experience changes our
internal language barriers and then go to GCC with a set of
requirements.

(Since I know the question will come up, possibilities are numerous --
basically we want to emit something on the RTL level, I think, though
I'm sure there will be much back-and-forth here; and licensing-wise, it
might involve a build server (already planned), or a plugin, or a
library. It will take a couple years I think.)

>    - 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.

At the very least it's an interesting tool to have! Though I do agree
though that it's not ideal.

> (I can clean up and post my notes on different code generation systems
> if you'd like them.)

I would be very interested in your observations, yes :)

> Thank you
> Noah Lavine

Thank you!

Andy
-- 
http://wingolog.org/



  parent reply	other threads:[~2010-06-01  9:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-27 21:03 Lightning Bindings Noah Lavine
2010-05-28 20:49 ` 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 [this message]
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=m3d3wbqfzs.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=noah.b.lavine@gmail.com \
    /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).