Re: on native compilation

[Sjoerd van Leent <svanleent@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

Reading the written thoughts below, what was the actual reason no to use
GNU Lightning? Has that too many complexities or incompatibilities to be
used for Scheme and other functional languages opposed to it's native GNU
Smalltalk?

I ask this since recently GNU Lightning 2.0 has seen the light, and I just
wonder if it would be wise to reinvestigate.

Any thoughts?

2013/9/2 Nala Ginrut <nalaginrut@gmail.com>

> On Sun, 2013-09-01 at 13:12 +0200, Andy Wingo wrote:
> > Hi,
> >
> > We have a bit too much on our plates ATM to think about native
> > compilation.  However, "what's the plan" is a common question.  So here
> > is a tentative plan.  Sometime after 2.2 settles down would be the time
> > to look at it.  It would probably be Guile 3.0.  Dunno.
> > The way to do it is to refactor compile-rtl.scm / assembler.scm /
> > disassembler.scm to emit and disassemble native code instead.  We get to
> > keep lots of parts of the existing compiler though: the ELF linker, the
> > constant allocator, all the metadata-related things (both on the
> > compiler and runtime side).  In this way it's a less brusque change than
> > the one from the stack VM to the RTL VM.  A first crack at the problem
> > would not do register allocation and would just emit code for each VM
> > op.  Later we could do proper register allocation.
> >
>
> Alright, so that means we'll do all the arg-passing work with stack at
> very beginning. I think it's a fair choice for such complex compiler
> stuffs.
>
> > It's probably easiest to have a native-only system rather than a mixed
> > native+VM system, as that way you would just have one stack.  We'd keep
> > the VM around of course -- it's just that a given build of Guile would
> > either be VM-based or native, chosen at build-time.  There's lots of
> > stack-related questions to sort out.
> >
>
> I'm glad to see AOT would be optional for users, since many users need
> portable objcode.
>
> > Anyway, that's a pseudoplan.
>
> Thanks for the working! ;-)
>
> >
> > Andy
>

[-- Attachment #2: Type: text/html, Size: 2730 bytes --]