This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: debug evaluator is faster than regular one?
Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> > % guile
> > guile> (time (do ((n 1000000 (1- n))) ((< n 0))))
> > clock utime stime cutime cstime gc
> > 8.64 8.5 0.14 0 0 6.5
>
> You're running the debug evaluator here as well.
Do you mean the interactive session always uses the debugging evaluator?
That sounds reasonable.
> Have you studied the technology used in QScheme before starting work
> on your own VM?
Yes, I looked at their VM. I originally tried to port it to Guile,
but I found that writing it from scratch is easier for me, and I
thought I could write better code. Is there any problem with looking
at their code?
The basic idea is the same. I use GCC's `&&' operator to get labels'
addresses and execute "goto *pc;" to run VM's instructions. The
instructions are defined like this:
SCM_OP (push, "%push", OP_NONE)
{
PUSH (v0);
NEXT;
}
SCM_OP (pushq, "%pushq", OP_SCM)
{
PUSH (FETCH ());
NEXT;
}
This becomes
op_push:
{
*sp++ = v0;
goto *pc++;
}
op_pushq:
{
*sp++ = *pc++;
goto *pc++;
}
My VM also has a debugging engine as well as a fast engine, using
the same idea as the Guile's evaluator :) In the debugging engine,
the NEXT macro runs a hook, for example, and I can easily add
debugging features:
% guile-vm
guile> (define bytecode (make-bytecode #(%pushq 1 %loadq 2 %popload add2)))
guile> (define vm (make-vm))
guile> (vm-set-option! vm 'debug #t)
guile> (add-hook! (vm-next-hook vm)
(lambda (vm)
(display (vm-fetch-program vm (vm:pc vm)))
(newline)))
guile> (vm-run vm bytecode)
(%loadq (#<bytecode 0x8094680> . #f))
(%call)
(%pushq 1)
(%loadq 2)
(%popload)
(add2)
(%return)
(%halt)
3
guile>
I'll write more about this later on and ask people about its architecture.
Thanks,
Keisuke Nishida