Re: Byte-code compilation - good for loading.

[Jim Blandy <jimb at red-bean dot com>]

> All the arguments I've seen on the list regarding byte code
> compilation have been to wrt run speed vs the current guile
> interpreter.  I just realized, though, that that there's another
> reason for byte code compilation that's quite orthogonal to this -
> loading byte code files could be much faster than loading straight
> scheme code.  One could even consider not writing a byte code
> interpreter, but just adding byte code reading & writing - i.e. -
> reading byte code directly into guile's internal tree code (or
> whatever it's called).  Has anyone looked into anything like this?
> Any obvious reasons why it wouldn't work?

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.

* 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.)

* 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.

* 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.

* I believe a bytecode interpreter need be no slower than SCM.  But
this is just uninformed arrogance on my part.



I do *not* believe that any of these benefits will automatically
appear with any arbitrary bytecode interpreter design.  But
intuitively, it seems easier to satisfy all those constraints
simultaneously with a design that segregates source analysis and
execution, and which uses simpler data structures for execution.

This post is not a design.  It includes no measurements.  It includes
no running code.  Therefore, please, please, do not construe it as an
argument in favor of bytecode designs --- a proper argument includes
evidence of some sort, and I have none.  I'm just saying that, if I
had to choose an approach, this is where I'd start, because it all
seems to hold together well at an intuitive level.