This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: guile-vm-0.0
- To: Keisuke Nishida <kxn30 at po dot cwru dot edu>
- Subject: Re: guile-vm-0.0
- From: Marius Vollmer <mvo at zagadka dot ping dot de>
- Date: 29 Jul 2000 14:26:12 +0200
- Cc: guile at sourceware dot cygnus dot com
- References: <m3d7jxa9gv.fsf@indy.STUDENT.CWRU.Edu>
Keisuke Nishida <kxn30@po.cwru.edu> writes:
> Okay, now it's somehow working:
Nice! I think I might want to get into a friendly competition with
your VM with my tree-compiler. Right now, your VM runs circles around
my evaluator, probably because you have inline functions, while I
don't.
However, the first point that struck me: does your VM perform
tail-call optimizations, as required by the RnRS? I couldn't test it
myself, because the compiler failed for me like this:
(define code (compile '(letrec ((l (lambda () (l)))) (l))))
/usr/local/share/guile/vm/bytecomp.scm:337:12: In procedure error in expression (error "Unknown tag:" tag):
/usr/local/share/guile/vm/bytecomp.scm:337:12: Unknown tag: #:apply
ABORT: (misc-error)
> ** Environment
>
> Local variable:
>
> (let ((a 1) (b 2) (c 3)) (+ a b c)) ->
>
> %pushi 1 ; a
> %pushi 2 ; b
> %pushi 3 ; c
> %bind 3 ; create local bindings
> %pushl (0 . 0) ; local variable a
> %pushl (0 . 1) ; local variable b
> %pushl (0 . 2) ; local variable c
> add 3 ; ac = a + b + c
> %unbind ; remove local bindings
This is what makes me worry about your VM not being tail-recursive:
"+" is in a tail position, but you call %unbind after calling "+".
Maybe this is only because + is a builtin and is known not to require
tail-call optimizations.
I guess your primary goal is to improve the speed of Guile, right? I
want to reduce loading time, on the other hand. So hopefully, we can
combine our efforts and have high speed and fast loading.
To get near the speed that you have, I would need to support builtin
functions like +, -, <, cons car, and stack-allocation of environment
frames that allow this, right?
(Don't benchmark my evaluator with `do', I translate this into the
equivalent `letrec' without any environment optimizations, which
totally sucks performance wise.)