Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!home.csc.ti.COM!bartley
From: bartley@home.csc.ti.COM (David Bartley)
Newsgroups: comp.lang.scheme
Subject: Byte code speed
Message-ID: <8712182044.AA05200@home>
Date: 18 Dec 87 20:44:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 40

> From: NETWORK%FRSAC11.BITNET@mitvma.mit.edu
> A while ago there was some mail about benchmarking Scheme, what's
> new about that ?
> Using the very simplistic (fib 20) test I was surprised to get very
> good results on my M24 running TI PC Scheme 2.0, and quite good one
> for MacScheme. This compared to straight interpreters. (Lisp interpreters,
> vs Byte code interpreters).
> 
> My question is: Where can I get description of the byte code used by
> TI PC scheme ? How about the compiler and the byte code interpreter ?
>    [...]
> Jean-Pierre H. Dumas

The only description of our work in the open literature is the paper
entitled ``The Implementation of PC Scheme'' in the proceedings of the
1986 ACM Conference on Lisp and Functional Programming, pp 86-93.
Although it doesn't disclose nitty-gritty details, the paper explains
the general nature of our byte-threaded-coded virtual machine and
gives some examples of its instruction set.  It also has an overview
of the compiler and a listing of the 8088 code for the 5-instruction
``next'' operation of the emulator.

> As far as I have observed PC Scheme GC somewhat less than CSCheme,
> From old popular wisdom (here, in France) it is said that the speed
> of an interpreter is strongly related to the use of "CONS" for the
> own use of the interpreter itself, and I have the feeling that
> PC Scheme "conses" less than CScheme too. (I am surely wrong, it
> is just a feeling. But the popular wisdom seems solid.)

Our emulator does no consing on its own except to extend the stack
when it overflows.  Until release 3.0, PC Scheme had no interpreter at
all.  It now mixes interpretive and compiled execution in the
following way: An S-expression given to EVAL will be interpreted until
a subproblem is encountered which involves variable binding (e.g., a
LAMBDA, LET, or LETREC).  The subproblem is then compiled and executed.
As a result, simple expressions like (DEFINE X 3) and X are interpret-
ed, but the procedure in (DEFINE F (LAMBDA (X) ...)) is always compiled.

Regards,
David Bartley