Re: (no subject)

[Rob Browning]

Han-Wen <address@hidden> writes:

> I'm just wondering -- Some time ago Keisuke Nishida (sp?) was
> working on a byte compiler for GUILE that offered major speedups in
> many cases. Is that still being pursued?

Not at the moment.  He had to stop working on that (at least for a
while), and I can't recall if he though he'd be able to get back to
it.

Regardless, I think the general plan was to first get the evaluation
process cleaned up a bit and then step back and consider what comes
next.  There as been discussion of scm->c, jit, lightning-based-jit,
gcc-front-end-based[1], and traditional byte compilation.  Once the
evaluation process better separates memoization and execution from
each other and from the other steps (a la Dirk's current work).  It
should be a lot easier to explore the possibilities.

[1] which with the addition of -foptimiize-sibling is now at least one
    step more likely to be feasible, though perhaps still not the
    right idea.  I'm still not sure that gcc's intermediate language
    has all the features you'd really need.

    Interesting related link:
      http://gcc.gnu.org/frontends.html -- see FLIM -- a realy simple
      example gcc front end, and Ksi, a compiler from a very thin sexp
      representation of gcc's intermedate trees to machine code, and
      Gont a high level language that spits out forms to be processed
      by Ksi on the back-end.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD