guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: let's bytecode it!


From: Mikael Djurfeldt
Subject: Re: let's bytecode it!
Date: Fri, 25 Apr 2008 10:36:41 +0200

2008/4/25 Ludovic Courtès <address@hidden>:
>  Guile-VM is written as an independent project currently, so I don't
>  think it would fit well into core Guile, and I'm actually not sure it'd
>  be a good idea to put it there, at least for now.

[Jumping in again although I shouldn't since I don't normally follow
activity on the list.]

I might be missing something, but I think Andy's idea of putting
guile-vm in the core is obviously the right thing to do.  In fact, as
soon as the vm is fully functional and stable (which may take time, I
grant you that) I think it should replace the current evaluator except
possibly for debugging.  (Currently, the evaluator code is compiled
twice---once for generating the sluggish version of the evaluator, and
yet another time to produce the even more sluggish debugging
evaluator.  A vm could replace the sluggish evaluator.  The debugging
evaluator could be kept for supporting backtraces and the debugger.)
I wanted to do this from the first instance when I tried out Keisuke's
vm, but could never find time to do it.  Even though other properties
of Guile *should* be reasons for people to use Guile, I'm personally
convinced that people take the slugishness as a sign of poor code and
think this is the major reason why Guile hasn't been adopted to an
extent several magnitudes more than currently.

Another note: The author of QScheme (which has a very efficient
byte-code interpreter) once teamed up with us with the aim to combine
ideas from QScheme and Keisuke's vm to implement the Guile bytecode
interpreter, but this never got started for real.  Maybe it's worth
looking at QScheme?

Also, if I moved a bytecode interpreter into the core, I would
probably look at the possibility to place GOOPS method dispatch as a
central mechanism---maybe this could be the only form of type
dispatch?  I would try to remove type checking in all Guile primivites
and move the responsibility for this to this core dispatch mechanism.
In order not to loose backward compatibility for those using the Guile
API from C in their applications, one could have type-dispatching
glue-code with the old C API names.

But if this seems too futuristic, just replacing the sluggish
evaluator with the vm would give Guile a major boost.  Be sure to test
it against code using threads, though...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]