Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!gatech!swrinde!pipex!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Re: GEL #f/nil, SCM choice
Message-ID: <uBuPVc2w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
References: <3a3h2v$1ie@jive.cs.utexas.edu>
Date: Sun, 13 Nov 1994 06:24:41 GMT
Lines: 48

wilson@cs.utexas.edu (Paul Wilson) writes:

> better to use a representation that's closer to the compiler's late-back-end
> intermediate representation, because that gives the native code generator
> more of a chance to optimize things.  Bytecodes generally overcommit
> to a lot of things, and the native code generator has to work pretty
> hard to reverse-engineer what a bytecode sequence means and optimize it.
> I think (but am not sure) that you'd be better off with a more expressional
> intermediate form that could either be compiled or interpreted.

Howdy,
        I've been banging on a bytecode compiler for CL and
am reasonably happy with it, given its intended purpose and
constraints (embedded CL for a scripting language, Windows 3.1,
.DLL implementation with attendant headaches).
        I've also been toying with a small Lisp compiler "in
my spare time" that would generate native code. I have to 
agree with your comment that "bytecodes generally overcommit".
In fact, our empirical observation have shown us that at least
for a 386, once the compiler takes a whack at the code, fat
"overcommited" instructions are a speed win in general. 
(Sorry, no science here to report. We just take some medium
sized apps, like a toy prolog or a little NLQ system or a 
basic->lisp compiler, etc. and run em and see how fast they
go and where they spend their time using pretty crude measures.)
        Anyway, though my native code compiler is only in
"hobby mode" and I've made some progress, I'M NEVER HAPPY WITH
THE INTERMEDIATE REPRESENTATION.  For example, the latest
incarnation of the thing generates good 'ol 3 address code.
While this makes it simple to do register allocation, 
"peephole" optimization, etc - this seems pretty useless
for transforming local tail calls into loops, doing type
inference, etc.
        Are there any "accepted" or "popular" IR's that
are well documented for Lisp like languages? I'd especially
be interested in something that handles all the weirdness
of Common Lisp (both static and dyanmic binding, multiple
values, complex lambda lists, blocks names/go tags of
dynamic extent, etc.) I've picked up tidbits here and
there in "the literature", but it's like having one
hand on an elephant.  
        Any and all advice, information, literature
pointers would be much appreciated.

=============================================
Scott McLoughlin
Conscious Computing
=============================================
