() Noah Lavine noah.b.lav...@gmail.com
() 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
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
Hi Noah,
On Tue 01 Jun 2010 00:49, Noah Lavine noah...@gmail.com 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
On Tue, Jun 1, 2010 at 5:06 AM, Andy Wingo wi...@pobox.com 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
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
Hello,
Noah Lavine noah.b.lav...@gmail.com 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
Hi Noah!
Noah Lavine noah...@gmail.com 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
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
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
() Noah Lavine noah.b.lav...@gmail.com
() 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
is that it would be C. Writing
lightning assembly can be tedious, but probably less so if done in
Scheme.
- First, would you like Lightning bindings?
Yes! :-)
- Second, what would a good interface to a native code generation
system be? (I'm assuming we'll want Lightning available as a regular
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
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
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
14 matches
Mail list logo
