Re: What's the current recommendation for speeding up bits of guile code.

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> So is there a plan, and have we overlooked other options?

What I like to do is to have a sort of compiler framework that can
generate code for a portable byte code machine or for GNU Lightning, a
JIT compiler.

I don't know whether I'd like to have the byte codes sit below
Lightning (that is, GNU Lightning generates code for the byte code
machine) or whether it should sit above Lightning (that is, we
generate machine code from the byte codes).

I think some sort of hybrid approach might be best, where we have a
compiler that generates some very simple intermediate form (like a
variant of Scheme with stack allocation and explicit heap consing of
environment frames where this is necessary, and no non-toplevel
closures, say).  We could then generate byte codes from that, or
compile it to machine code using Lightning.

I have some working bindings to Lightning for Guile, that I want to
check in in the next days.  You can't really do anything advanced with
it, but it's a start.  For example, I can do this:

    (use-modules (lightning))

    (define c (assemble '((leaf 1)
                          (arg n)
                          (getarg r0 n)
                          (add ret r0 4)
                          (ret))))

    (disassemble c)

    (format #t "~A\n" (c 2))

And get this output

    0805e62c    push   %ebp
    0805e62d    mov    %ebp,%esp
    0805e62f    push   %ebx
    0805e630    push   %esi
    0805e631    push   %edi
    0805e632    mov    %eax,DWORD PTR [%ebp+8]
    0805e635    add    %eax,4
    0805e638    pop    %edi
    0805e639    pop    %esi
    0805e63a    pop    %ebx
    0805e63b    pop    %ebp
    0805e63c    ret    
    3

The next things will probably be to have a way to have calls to
primitive procedures like scm_sum, to specify a tail-callable calling
convention for GNU Lightning (I want to look at CMUCL for this), and
to investigate `fasl' methods (maybe based on Keisukes work).

Of course, it is very important that Guile remains highly portable, so
these compiler ideas can only be an extra.  We need to always have the
option of using a portable interpreter, either the existing one or
another virtual machine.  I think that a byte code engine can make
good use of large parts of a `real' compiler that targets a `real'
machine language, so I hope that we actually have synergy when working
on both a byte code machine and a real compiler.