on native compilation

on native compilation

[Andy Wingo]

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.

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.

Anyway, that's a pseudoplan.  

Andy
-- 
http://wingolog.org/

Re: on native compilation

[Nala Ginrut]

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

Re: on native compilation

[Sjoerd van Leent]

[-- 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 --]

Re: on native compilation

[Andy Wingo]

Hi,

On Sun 08 Sep 2013 20:19, Sjoerd van Leent <svanleent@gmail.com> writes:

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

It makes sense to investigate, yes.  However the issue is more one of
getting getting the right abstractions in Guile, and it's not clear that
Lightning provides them.  Lightning is for JIT compilation, and we want
to do AOT first.  I think it makes sense to get native code for one
architecture, see how that interacts with our needs for debugging, then
start to think if an existing project's code generation abstractions
suit our needs.

Andy
-- 
http://wingolog.org/