Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!labrea!decwrl!decvax!tektronix!tekcrl!tekchips!willc
From: willc@tekchips.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Scheme on a PC?
Message-ID: <1654@tekchips.TEK.COM>
Date: Tue, 1-Sep-87 17:17:19 EDT
Article-I.D.: tekchips.1654
Posted: Tue Sep  1 17:17:19 1987
Date-Received: Thu, 3-Sep-87 04:49:23 EDT
References: <316@m10ux.UUCP> <527@yetti.UUCP> <678@hplabsz.HPL.HP.COM> <646@cup.portal.com> <121@faccs.UUCP>
Reply-To: willc@tekchips.UUCP (Will Clinger)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 49
Bcc: willc

In article <121@faccs.UUCP> dbt@faccs.UUCP (Data base translator ) writes:
>MacScheme, for the Macintosh, is coming out with a native code compiler as
>well. I don't know what the code generation is like. (I would appreciate any
>information about this one in particular. e.g. is the native code compiler
>an modification of the original byte-code compiler?)

For the moment at least, the MacScheme native code compiler is available only
as part of MacScheme+Toolsmith.

The native code compiler is indeed a modification of the original byte code
compiler, which was described in my 1984 Lisp conference paper.  The original
compiler had one pass, but the new one has three: macro expansion, code
generation, and assembly.  The first two passes are the same for byte code
as for native code, but there are two assemblers.  The assembly pass decides
which assembler to use for each code segment (i.e. lambda expression) as
specified by the programmer.

Though the new three-pass compiler is slower than the old one-pass, it
seems faster because character i/o, which has always been the bottleneck,
has been sped up.

"Optimization" takes place in all three passes:  simple	source code
transformations in the macro expansion pass, a few simple optimizations in
the code generator, and peephole optimizations in the native code assembler.
With more peephole optimizations and perhaps a few more optimizations in the
code generator the code would be fairly decent, but right now it's merely
competitive.

It compiles very good code for loops but does poorly with procedure calls.
(Using generic arithmetic a Macintosh II can count down from 1,000,000 in
4.5 seconds, which is very good, but (tak 18 12 6) takes 2.3 seconds, which
is mediocre.)  The representation used for continuations was changed for the
native code compiler, but the byte code representations are still used for
procedures and environments.  These representations appear to be the main
limits to performance.

Exceptions in native code are handled by dropping into byte code and letting
the byte code exception handler deal with it.  The exception handler and byte
code debugger are therefore used for native code as well as byte code.  This
is why native code and byte code use the same representations.

There isn't much difference between a compiler that compiles to byte code and
one that compiles to native code, so it's fair to say that nearly all
implementations of Scheme are compiled.  The PC Scheme byte code compiler,
for example, is quite a bit more sophisticated than the MacScheme compiler
even though it always generates interpreted byte code.

Peace,
William Clinger