[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What's the current recommendation for speeding up bits of guile code
From: |
Marius Vollmer |
Subject: |
Re: What's the current recommendation for speeding up bits of guile code. |
Date: |
20 Mar 2001 00:33:25 +0100 |
User-agent: |
Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 |
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.
- What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/19
- Re: What's the current recommendation for speeding up bits of guile code.,
Marius Vollmer <=
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/20
- Re: What's the current recommendation for speeding up bits of guile code., Eric Moore, 2001/03/20
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/20
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/20
- Re: What's the current recommendation for speeding up bits of guile code., Martin Grabmueller, 2001/03/21
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/21
- Re: What's the current recommendation for speeding up bits of guile code., Marius Vollmer, 2001/03/23
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/23
- guile performance too slow for gnucash?, Neil W. Van Dyke, 2001/03/23
- Re: guile performance too slow for gnucash?, Rob Browning, 2001/03/23