Subject: Re: LISP for embedded systems
From: (Rob Warnock)
Date: 1999/10/26
Newsgroups: comp.lang.lisp
Message-ID: <7v3q4q$>
Rainer Joswig <> wrote:
| (Rob Warnock) wrote:
| > But as soon as you so something more complicated, SIOD's simple
| > interpreter starts to fall behind other implementations which do
| > some sort of preprocessing (compiling or "half-compiling") or
| > shallow binding of lexicals, etc..
| You can do some preprocessing in SIOD, too.
| We use SIOD so that we load a toplevel file which requires
| a lot of other files (maybe upto twenty I think).
| All these files can be combined in one "preprocessed" file.

O.k., I assume you're talking about the "csiod" tool, which reads
a bunch of forms and writes them in FASL format, prepended by a
"#!/path/to/siod" header. Yes, that helps startup times for larger
programs, but *doesn't* help the post-startup performance at all!

When I said "preprocessing", I was refering to more aggressive things,
like stack-allocating lexical vars that aren't captured in closures,
beta reductions (where it's safe to do so), etc.

But SIOD does no rewriting of S-exprs at all. It's still a "pure
interpreter". In fact, it doesn't even memoize macro expansions!
They're re-expanded every time the enclosing forms are executed.

By comparison, even though SCM is also a pure interpreter, it at
least preprocesses (well, lazily rewrites then memoizes the first
time a closure is evaluated) lexical variables into "depth+offset"
tokens to speed lookups, and expands macros only once. And MzScheme,
of course, does "real compiling" of all expressions (also doing macro
expansion once only, at compile time).


p.s. Perhaps we should take this offline, or at least move it to
comp.lang.scheme.  ;-}

Rob Warnock, 8L-846
Applied Networking
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		FAX: 650-933-0511
Mountain View, CA  94043	PP-ASEL-IA