Re: Byte-code compilation - good for loading.

[Jorgen `forcer' Schaefer <forcer at mindless dot com>]

Jim Blandy <jimb@red-bean.com> writes:

> Just for the record, here's why I was interested in bytecode
> interpreters:
> 
> * I believe a bytecode interpreter could provide full support for
> source-level debugging at a much lower time overhead than the current
> design.  I think debugging support is extremely important.

Considering the advantages Michael Vanier mentioned in his post
about Juic (http://caesar.ics.uci.edu/juice/intro.html),
shouldn't it be possible to have a tree-level representation in
guile which can be as easily debugged as bytecode?

Deviating from the current design, there should be a format we
could think of...

> * I believe a bytecode interpreter could improve Guile's
> maintainability, by relegating the analysis of the source forms to an
> entirely separate phase from execution.  Each part of the process has
> simpler responsibilities, making it easier to write maintainable and
> efficient code.  (This would also fix Guile's current problems with
> macro memoization in multi-threaded code.  Marius and Mikael know what
> I'm referring to.)

That doesn't necessarily ask for a byte-code interpreter per se,
just for some more abstraction between the layers :)

> * I believe a bytecode interpreter could provide much higher code
> density than the current representation.  If Guile is stretching the
> processor's data cache, this might improve speed, too.

Hmm. A `bytecode' in the notion of a different storage format
than scheme source would certainly be a Big Win. But how do you
want to strech the processor's data cache, if we always have to
interpret the next byte code?

Bytecode has it's advantages, but speed surely isn't one of them :)

> * I believe a bytecode could be a better target for multiple language
> support than Scheme.  I think common target languages should be very
> low-level and concrete, since this leaves more implementation choices
> in the hands of language-specific code, where they can be decided
> appropriately.

Or a tree-representation like gcc.
You think of the GVM, Guile Virtual Machine, just like the JVM,
so that languages can be compiled into it? I don't know wether
that's a really good idea :]

A few things that might be helpful to those who have more
knowledge than me in this matter..

Bytecode (or binary format, or whatever) enhances loading
speed, e.g. (read)-speed, not necessarily (eval)-speed.
Guile should have an internal format that can be written out,
just like .elc oder .pyc, because loading speed is important
sometimes :)
If this format can then be easily translated into gcc's tree
representation, we would all of a sudden have a very good
compiler. But that could wait for some other time. (it surely
needs improvements on the gcc side of things)

A normal bytecode throws away too many information that can be
useful (see juice). We should think about this twice.

So in conclusion, what i think we (we? those who understand guile
better, and me maybe if i find the time to read into guile more
than i have now, instead of telling everyone what "we" should do
*cough*) should do is:
- Define an internal tree format (maybe based on the current one)
  which can be written out and read in easily.
  This format should be chosen in a way that it makes a parsing
  in (read) almost unnecessary.
- (eval) should be more abstracted from (read).
  Ideally it shouldn't modify anything in the tree structure.
  That could be done by a special optimize function?

Hmm
I think i better stop now :)
HTH,
	-- forcer

-- 
((email . "forcer@mindless.com")       (www . "http://forcix.cx/")
 (irc   . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))