Path: utzoo!attcan!uunet!yale!Krulwich-Bruce
From: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich)
Newsgroups: comp.lang.scheme
Subject: Re: dynamic compilation for scheme, with inlining, etc?
Message-ID: <38554@yale-celray.yale.UUCP>
Date: 22 Sep 88 17:56:36 GMT
References: <8809142159.AA28551@uicbert.eecs.uic.edu> <327@scaup.cl.cam.ac.uk>
Sender: root@yale.UUCP
Reply-To: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 50
In-reply-to: adg@cl.cam.ac.uk (Andy Gordon)

In article <327@scaup.cl.cam.ac.uk>, adg@cl (Andy Gordon) writes:
>In article <8809142159.AA28551@uicbert.eecs.uic.edu>
>wilson@uicbert.eecs.uic.EDU (Paul Wilson) writes:
>>I've been thinking about using dynamic compilation for Scheme,
>>and wondering if anybody else is.  Have people abandoned the idea
>>of dynamic compilation, and if so, was it premature?
>
>Firstly, by "dynamic compilation" I understand a system that
>represents a programme to start with as a syntax tree or some other form
>suitable for interpretation, but compiles parts of it into native code
>as execution proceeds.  Interpreted code is generally smaller than compiled
>code so less space is needed than compiling the whole thing.

I think you're overlooking several possible program transformations that could
be done in addition to straightforward compilation, such as:

	(1) Inlining functions and de-inlining them when necessary
	(2) Different levels of compiled-code optimization
	(3) Caching of results
	(4) Special case handling of parameters by type
	(5) Analysis of memory use to reduce garbage generation
	(6) Dynamic analysis of ordering of comparisons

>There appear to be two reasons for hybrid systems: (1) to give a variable
>time/space tradeoff, i.e., between fast/bulky native code and slow/lean
>interpreted code; (2) to allow fancy interpretive debuggers and tracers
>in the presence of native code.
>
>I don't think reason (1) is very compelling these days, because the size of
>compiled code is not an issue with today's computers---certainly, big ML
>programmes that are compiled to native code by one of the production compilers
>don't take up inordinate space.  

As I said above, I would bet that this does become an issue when more possible
transformations are considered.

>However, reason (2) is still attractive, because interpreted code will always
>be easier to debug than compiled code.  A dynamic hybrid system is all the
>work of a static one, and more, so for it to be worthwhile it must make
>debugging much easier.  One can imagine a debugger threading through a
>programme, seeking to use interpreted versions of compiled functions as it
>finds them---maybe you could keep a pointer in each compiled function to an
>interpreted version or the source.  I'd be interested to hear how you get on.

This is a good point.  Similar uses might be the ability to redefine a
component of a function without recompiling the entire function, or the 
ability to optimize only the inner loops of a function, 


Bruce Krulwich