Re: Byte code speed

[Will Clinger <willc%tekchips.tek.com@RELAY.CS.NET>]

David Bartley of TI wrote concerning PC Scheme:

    Our emulator does no consing on its own except to extend the stack
    when it overflows.

In the sense intended by David this is true of MacScheme 1.5 also, but
it depends on what is meant by "on its own".  Besides the byte codes that
obviously allocate storage, such as cons and make-vector, there are byte
codes such as + that allocate storage on occasion.  Of more interest are
the byte codes that create closures, that allocate lists for rest arguments,
and that allocate heap storage for variables that are closed over by lambda
expressions (unless this is done by the byte codes that create closures).
Clearly both PC Scheme and MacScheme have such byte codes.

I think the French wisdom is that fast interpreters do not allocate
garbage-collected storage for argument lists, implicit temporaries,
or continuations.  This is true of PC Scheme and MacScheme 1.5, but older
versions of MacScheme were significantly slower than Version 1.5 in part
because they allocated continuations on the heap.  It's interesting that
the original design back in 1983 called for stack-allocated continuations,
but the heap-allocated continuations that were used as a temporary
measure during the bootstrap ran fast enough (because of a fairly fast
garbage collector) that there wasn't much pressure to change it until the
native code compiler was added this spring (by Eric Ost and Anne Hartheimer).

Peace, Will Clinger