This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Byte-code compilation - good for loading.
> Mailing-List: contact guile-help@sourceware.cygnus.com; run by ezmlm
> Precedence: bulk
> List-Unsubscribe: <mailto:guile-unsubscribe-mvanier=bbb.caltech.edu@sourceware.cygnus.com>
> List-Subscribe: <mailto:guile-subscribe@sourceware.cygnus.com>
> List-Archive: <http://sourceware.cygnus.com/ml/guile/>
> List-Post: <mailto:guile@sourceware.cygnus.com>
> List-Help: <mailto:guile-help@sourceware.cygnus.com>, <http://sourceware.cygnus.com/ml/#faqs>
> Sender: guile-owner@sourceware.cygnus.com
> Cc: "Harvey J. Stein" <hjstein@bfr.co.il>,
> guile@sourceware.cygnus.com
> From: Jim Blandy <jimb@red-bean.com>
> Date: 20 Dec 1999 19:41:44 -0500
>
>
> > > * I believe a bytecode interpreter need be no slower than SCM. But
> > > this is just uninformed arrogance on my part.
> >
> > You didn't mention using dynamic compilation in addition to a bytecode
> > interpreter. Any particular reason why?
>
> I don't really have enough experience with native code generation to
> say anything helpful about it.
>
> For example, I'm not at all sure that bytecode makes better input for
> JIT compilers than the trees Guile uses now. If the bytecode is
> stack-based, then the compiler has to un-stack it to rediscover the
> dataflow, whereas Guile's trees are a lot like parse trees.
>
In this context, the work on the Juice compiler for Oberon is of interest.
See http://caesar.ics.uci.edu/juice/intro.html for a description. They
claim that a tree-code format is actually denser and produces faster code
than bytecode.
Mike