guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lightning Bindings


From: Andy Wingo
Subject: Re: Lightning Bindings
Date: Tue, 01 Jun 2010 11:06:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hi Noah,

On Thu 27 May 2010 23:03, Noah Lavine <address@hidden> 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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]