This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: New Guile VM


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Daniel has suggested adding an optional assembly step generating
> machine code.

Is it as easy as executing byte codes?  I think the most important
thing is not speed but to write a VM that works with Guile as soon as
possible.  We can improve it later.

I guess it is not so easy to directly port QScheme to Guile because
Guile has its own primitives and we need to use them; that's why I
started writing my own VM.  Probably it is better to start from my
VM implementation, absorbing QScheme's ideas and features.

Dan, what is your basic idea for this merger?  Are you going to
modify your VM for Guile?  Or do you want to improve your VM with
QScheme first?  Anyway, it is good for me to be able to talk to you :)

> Also, I have a bunch of disordered plans to write a new Guile
> interpreter.  Since there will be quite a while before I can spend
> enough time to realize these plans, I've decided to make them public,
> so that anyone who is interested enough to decipher them can do so.
> 
> I'll put them in the guile-core/devel directory.

Looks interesting, but it will take quite a long time.  How would you
draw a road map toward the new interpreter?  I would suggest this:

 1. Write a VM and a compiler that evaluates R5RS without modifying
    the current Guile's core.

 2. Add a support for the current module system and a feature of
    bytecode saving/loading to/from files.

    After this, a VM version of Guile 1.4.x can be released
    (if it is desirable).

 3. Add a support for GOOPS.  After the integration of GOOPS,
    the VM can be optimized for it.

 4. The support for the new module system will be here.

 5. The ior project will be after everything has come to work fine.

Optimizations like generating machine code can be done whenever
it is appropriate.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]