[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (no subject)
From: |
Rob Browning |
Subject: |
Re: (no subject) |
Date: |
Sun, 04 Aug 2002 13:38:13 -0500 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) |
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
- (no subject), Han-Wen, 2002/08/04
- Re: (no subject),
Rob Browning <=