unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Lightning Bindings
@ 2010-05-27 21:03 Noah Lavine
  2010-05-28 20:49 ` No Itisnt
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Noah Lavine @ 2010-05-27 21:03 UTC (permalink / raw)
  To: guile-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Lightning Bindings
@ 2010-05-31 22:49 Noah Lavine
  2010-06-01  9:15 ` Andy Wingo
  2010-06-01 18:02 ` Ludovic Courtès
  0 siblings, 2 replies; 15+ messages in thread
From: Noah Lavine @ 2010-05-31 22:49 UTC (permalink / raw)
  To: ludo; +Cc: guile-devel

Hi Ludo,

I didn't realize guile-lightning existed! It looks like that project already has most of the code for Lightning bindings, so it might be better to try to update it to work with Guile 2.0. I also saw your idea for JIT, which I could work on as well. However, all three projects use different ideas of how Lightning should connect to Guile, so before I code more I would like to talk about which would be better.

Here is my understanding of the three approaches:

The approach in my project was to make machine code a Guile datatype, which you could allocate with a special init function and write to with writing functions which are just Guile versions of the Lightning macros. It could be called as a function through the dynamic FFI.

The approach in the other guile-lightning project is to represent the Lightning code as a Guile list which mirrors the Lightning virtual instruction set. When a list is completely built, it would then be passed to a special function (written in C) to assemble it. It also has some infrastructure for labels and a special method of calling these functions, neither of which I understand yet.

The approach in your plan for JIT, as I understand it, is to implement this completely in the C layer. The machine code would be stored as part of the representation of a procedure, and would be invisible from the Scheme side.

(I should also point out that my plan for compilation was to first start generating machine code with as few inlined instructions as possible, which would just call VM functions to do its work. This was also your plan, and I believe also the plan of the earlier guile-lightning project.)

It is not clear to me which one of these is the best way, or even if there is a best way.

The reason I did not use the approach of the other guile-lightning, to make a list and then assemble it, was that it seemed inelegant and possibly slow to have to iterate through instructions twice whenever I compiled something, first to generate the list and then to compile it. However, I doubt it would be very slow, and thinking about it now it might even be faster if the iteration programs became smaller and fit in cache.

As for doing it all in C, I am concerned about this because if there were bindings available in Scheme, then it might be possible to write a nice compiler in Scheme someday, which would do clever things like inlining and interprocedural optimization. (Or, more easily, persuade the MIT Scheme or Bigloo people to donate their compilers.) Writing it in C could make that more difficult - but if it also made Guile programs faster right now, then it might be worth doing anyway.

What do you think of this? What way should I try to implement this?

Noah


^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Lightning Bindings
@ 2010-06-01 20:42 Noah Lavine
  0 siblings, 0 replies; 15+ messages in thread
From: Noah Lavine @ 2010-06-01 20:42 UTC (permalink / raw)
  To: ludo; +Cc: guile-devel

They claim that MELT is tightly integrated with GCC, but after reading http://gcc.gnu.org/wiki/MiddleEndLispTranslator, I don't believe it. The "MELT compiler implementation" description suggests that it's a pretty simple-minded sexp-to-C translator. I also notice that none of the examples has any control structures more complicated than `if` and `foreach`. I'd say it's basically a nice syntax for messing with GCC data structures.

When the page says "very tightly integrated into GCC", it seems to mean "has boxed versions of a few internal GCC data structures" (there's a list on the page I link. It's not very long). That shouldn't be hard at all to connect Guile to.

The only part that could be tricky is interfacing with GCC's garbage collection. I don't know how Guile's FFI interacts with other memory management systems, so this could be a problem, but I think it could be done. It's going to have to be solved anyway if Guile is going to interface with other memory management systems.

Besides, this is one of Guile's objectives, isn't it? GNU programs shouldn't need to implement their own extension languages, because Guile can handle it.

Noah


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2010-06-02 20:47 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

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