This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hello!
Sorry for this late answer to Jim Blandy's email.
> 1) Are you comparing the speed of your engine to the speed of Guile
> with debugging enabled, or Guile with debugging disabled, or SCM? [...]
I have used guile-iii "out of the box", with the single exception of
the optimization switch ('-O' -> '-O2').
But then the VM does not use 'gscm_car' but the fast macros of SCM.
> 2) Are you expanding (let ((var exp) ...) body) to
> ((lambda (var ...) body) exp ...), in the usual way?
The compiler does the following transformations:
- (or a b c) -> (cond (a) (b) (c)
- and -> if
- let* -> multiple, nested let
- case -> (see R4RS).
For nearly all of the other special forms, there is direct support.
So, no, I do not expand 'let' to 'lambda'. I have tried to avoid
overhead.
The compilers does not support the above transformations in
a "native" way because there were plans to use the compiler along with a
macro expander.
> 2) Analyzing code beforehand allows us to lay out local variables in
> an array, rather than a linked list, which should speed up variable
> references (which are *very* frequent).
Adding support for local variables that are neither captured nor
modified did not help very much. The method I have used consists of
pushing the values of the local variables on the stack of the VM
(which is a C stack). There are instructions for accessing these
values on the stack directly (i.e. without popping other values).
Example: A compilation of (let (a "asdf") (b 5) a) yields
--------------------
get-literal ...
push
get-literal ...
push
get-register 1
pop-times 2 (dumps the 'environment frame' of 'a' and 'b')
--------------------
There certainly is some room for improvement (because "asdf" and 5 are
side-effect free), but at least this code does not use any cells or
mallocs (and my compiler does not have a clue of "side effect freeness").
> [...] It shouldn't be much
> trouble to handle a few special forms, if you design the compiler to
> be open in the right way.
Nearly all of them are in there already.
Bye,
Johannes Abt
--
PGP Public Key availabe by finger
<URL:http://wwwcip.informatik.uni-erlangen.de/user/jsabt>
"I am returning this otherwise good typing paper to you because someone
has printed gibberish all over it and put your name at the top."
-- English Professor, Ohio University