() Noah Lavine
() Tue, 1 Jun 2010 10:57:15 -0400
I didn't realize GCC had a Lisp interface.
It has a recently (2009?) approved run-time plug-in system, for
which MELT is one example. Incidently, Emacs also has also recently
won approval for the development of a analogous architecture, so...
Greets,
On Tue 01 Jun 2010 16:55, Noah Lavine writes:
>> 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.
>
> You may be right; although I think actually with the FFI, it would be
>
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 a
Hi Noah!
Noah Lavine writes:
> 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
Hello,
Noah Lavine writes:
> I didn't realize GCC had a Lisp interface. Interfacing with GCC would
> be excellent.
MELT is a “middle end”, useful when writing optimization passes, but not
when writing a front-end.
> This is perhaps far-fetched, but I think the best thing would be if we
> could
I didn't realize GCC had a Lisp interface. Interfacing with GCC would
be excellent.
This is perhaps far-fetched, but I think the best thing would be if we
could persuade them to replace MELT with Guile. It looks to me from
the docs like MELT is yet another Lisp engine, which is exactly what
Guile
On Tue, Jun 1, 2010 at 5:06 AM, Andy Wingo wrote:
> Hi Noah,
Hi Andy!
> 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
Hi Noah,
On Tue 01 Jun 2010 00:49, Noah Lavine writes:
> The approach in [Ludovic's] 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.
Hi Noah,
On Thu 27 May 2010 23:03, Noah Lavine 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...
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 diffe
Hi Noah,
Noah Lavine writes:
> 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 Lightn
() Noah Lavine
() Thu, 27 May 2010 17:03:48 -0400
- 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
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 wrote:
> Neat!
>
> Have you looked into libjit? The only reason I bring it up is be
Neat!
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 wrote:
> Dear Guile Developers,
>
> After watching the discussion of native code
14 matches
Mail list logo
