Path: utzoo!utgpu!watserv1!watmath!att!rutgers!mit-eddie!bu.edu!xylogics!samsung!sdd.hp.com!decwrl!argosy!freeman
From: freeman@argosy.UUCP (Jay R. Freeman)
Newsgroups: comp.lang.scheme
Subject: Re: Free Macintosh Scheme
Message-ID: <614@argosy.UUCP>
Date: 16 Jul 90 18:56:27 GMT
References: <601@argosy.UUCP> <5598@hplabsz.HPL.HP.COM>
Sender: news@argosy.UUCP
Reply-To: freeman@cleo.UUCP (Jay R. Freeman)
Organization: MasPar Computer Corporation, Sunnyvale, CA
Lines: 76

In article <5598@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes:

>So, how does this version of scheme compare to xscheme and elk??

I don't know, I have never seen either one.

>Is it byte compiled??

In essence, no:  Source code written by the user is interpreted by a
virtual machine that is almost an SECD machine in the sense of (eg)
Henderson.  (Almost??  Well, the stack is a separate entity in its own
right, not a heap object, there is no separate "dump" register (things
get pushed onto the stack), and there are a few other registers for
various special purposes.)  The values of the symbols that name the
built-in primitives (eg "+", "car", "cons" ...) are (tagged) pointers
to compiled C routines that run the SECD machine.  Essentially all of
the built-in primitives are coded as C routines rather than written in
Scheme using a smaller subset of "real" primitives:  This structure
speeds up the interpreter at the expense of making it large.

The user never sees these C routines directly; that layer of the
architecture is visible only to me, since I do not distribute source.

These top-level C routines are in turn mostly written in terms of
other, lower level C routines that also know about the SECD machine,
and which (courtesy of the C preprocessor) are made to appear to me
like assembly-language code -- not 68XXX code, but, if you will, the
native assembler of the SECD machine.  Thus if I were coding up a 
simple version of binary addition I would write something like

PROC( add )
    ADD
    DROP
    CONTINUE
END_PROC

which the preprocessor would translate into

void add() {
    addMC();
    ++S;

    }

What's going on here is that the evaluator will have pushed the numbers
to be added onto the stack; this code adds the top two and pops the
stack.  "addMC" is (virtual) microcode for addtion, "S" is a pointer into
the array of tagged objects that constitutes the stack, and so on.

I can in principle create a compiler that will take Scheme source code
as input and produce a list of primitive addresses as output; this list
can get pushed into the continuation and executed.  I have such a compiler
partly done, but back-burnered.

Thus the implementation is not so much byte-coded as threaded, and
could support (but does not at present support) compilation in the
sense of Forth.

I hope that makes sense.
	
>Does it require any assembly language coding??

No.

>Can it support incremental GC??

No.  Given the current limits to physical memory of the Macintosh,
GC time is unlikely to bother anyone very much.  I could put in an
incremental GC system with no more than a moderately ridiculous amount
of work, should a need for one arise.  

Thanks for your interest.

                                            -- Jay Freeman

	  <canonical disclaimer -- I speak only for myself>