[Top][All Lists]

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

Re: Guile 2.2 TODO

From: Andy Wingo
Subject: Re: Guile 2.2 TODO
Date: Fri, 18 Oct 2013 11:56:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

On Sun 01 Sep 2013 13:03, Andy Wingo <address@hidden> writes:

> * Replace bytecode trampolines with RTL trampolines.
> foreign.c, control.c, gsubr.c, and continuations.c all have inline
> bytecode trampolines to implement calls to "foreign" things.  These need
> to be replaced with RTL trampolines.  This can be done now, I think, and
> doesn't depend on anything else, given that the two VMs interoperate.

I've now done this for gsubr.c.  The initial results look great from RTL
code, but as most things are stack VM code the temporary result is a
slowdown.  Hopefully we can switch over to RTL within a few weeks

> * Prompt, abort, and call/cc.

I did prompt and abort, sorta -- it actually ends up recursing through
the stack VM to abort and so continuations are not rewindable.  That
will get fixed soon but perhaps not urgently, given that compiling the
compiler doesn't depend on rewinding partial continuations.

> * Compiling all of Guile to RTL.

eval.scm compiles fine and appears to be around 50% faster, currently.
However it can't be loaded at boot-time due to some module bootstrapping
issues.  I need to fix that before we can bootstrap Guile off of an
RTL-compiled eval.  Boot-9 is tricky for similar reasons.  The rest of
things should work though; I'll be going through them one by one looking
for miscompilations.

> * Rip out GLIL, assembly, bytecode, objcode, the old VM, etc..
> This will be a final glorious set of commits :)

I'm getting very excited about this :)

> I think that's pretty much it.  Obviously it would be nice to get a lot
> of other things into 2.2 but this is the necessary bit.  I think we
> should shoot for a 2.1.0 release around 1 December; dunno.

I think we'll be ready on that date, code-wise, but documentation makes
a 2.1.0 release much less likely -- documenting things takes time.



reply via email to

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