Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.mathworks.com!udel!princeton!news.princeton.edu!blume
From: blume@dynamic.cs.princeton.edu (Matthias Blume)
Subject: Re: GEL #f/nil, SCM choice
In-Reply-To: oz@nexus.yorku.ca's message of Fri, 11 Nov 1994 04:02:18 GMT
Message-ID: <BLUME.94Nov11103530@dynamic.cs.princeton.edu>
Originator: news@hedgehog.Princeton.EDU
Sender: news@Princeton.EDU (USENET News System)
Nntp-Posting-Host: dynamic.cs.princeton.edu
Organization: Princeton University
References: <Cz0ADt.Gv@viewlogic.com> <39r0j0$han@nyheter.chalmers.se>
	<OZ.94Nov10230218@nexus.yorku.ca>
Date: Fri, 11 Nov 1994 15:35:30 GMT
Lines: 68

In article <OZ.94Nov10230218@nexus.yorku.ca> oz@nexus.yorku.ca (ozan s. yigit) writes:

   Tanel Tammet:
	   ...
      However, observe that there exists a scheme->C compiler Hobbit
      dedicated to scm. 

   how hard is it to make it generate code for vscm?

I don't know about this, but from what I've heard about Hobbit I
wouldn't be too interested anyway.  Hobbit is too restrictive on the
language.  If I can only write C-like Scheme to make it runs
efficiently, why bother?  ``If you need C you always know where to
find it...''

I also think that one of the main objectives of hobbit was to create C
output that more or less could have been written by human programmers.
VSCM's interface to C functions (as used to implement many of the
built-in primitives) forces a programming style not likely to be found
in ordinary C programs written by humans.

		   ... The existing Hobbit versions do not cover whole
      scheme (higher-order stuff is severely restricted), but the full one
      is in the works.

How will Hobbit deal with ``higher-order stuff''?  Just call the
interpreter?

   oz
   ---
   ps: i think making vscm compiler generate some sort of c code is
   not terribly hard, if the author cared. comments?

This is true.  For most of VSCM's bytecode instructions it is rather
straight-forward to emit equivalent C code.  The trouble spots are
calls to unknown funtions (e.g. functions passed as parameters).  A C
function in VSCM can never call a Scheme (bytecode) function
recursively by ``recursing into the virtual machine''.  Instead some
kind of ``continuation passing'' has to go on.  There are three kinds
of C functions:

	1. C function never calls any Scheme (bytecode) function

		This case is the easy case, no special precautions are
		necessary.

	2. C function may call bytecode function, but only in tail position.

		Little bit more tricky, but not too much.

	3. C function may call bytecode function in ``general'' position.

		C function needs to be split into several parts
		(initial entry point, continuation).  Tricky, not
		human-friendly.  Could easily be generated by
		compiler.

I know about a mechanism to translate VSCM bytecode to C, but I never
implemented it.  There are other issues to be considered -- for
example the issue of being able to create ``portable'' memory dumps.
While my memory management subsystem is able to save bytecode into
memory images (because bytecode is just one of my low-level datatypes
and bytecode is the same on all architectures) the same wouldn't be
true for compiled C.  Certainly, there are ways to deal with this
problem, but I just don't have the time.

--
-Matthias
