Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!news.maxwell.syr.edu!jfk3-feed1.news.digex.net!dca6-feed2.news.digex.net!intermedia!newsfeed1.cidera.com!Cidera!news-reader.ntrnet.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Glulx] branching to another function...
Message-ID: <GJDAxy.6pv@world.std.com>
Date: Sat, 8 Sep 2001 23:37:09 GMT
References: <e61ef191.0109081452.45f636f9@posting.google.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 49
Xref: news.duke.edu rec.arts.int-fiction:92385

Jon Zeppieri <97jaz@my-deja.com> wrote:
>(1) Before a non-tail call (from Scheme's perspective; from Glulx's
>perspective, all calls are tail calls) is executed, the current stack
>values are saved in a heap-allocated partial continuation.  The Glulx
>stack never gets deeper than a single call frame.

Did you leave out of this message "by the way, I'm trying to
implement a Scheme compiler"?

>(3) GC is, more or less by nature, a non-tail call.  That means that
>if GC were handled like normal Scheme functions, a continuation would
>have to be saved before it could be invoked.  That, in turn, would
>mean allocating a partial continuation-- but that's not an option,
>because there's no memory left (if there were, there would be no need
>to GC).

Pre-allocate a partial continuation at the dawn of time for use
by the GC system.

>(5) This would indicate that GC cannot be a separate Glulx function.
>It has to be, strictly speaking, part of the allocation/initialization
>function.  The problem, is that I want more than one allocation
>function; in fact, I'd like three, for cons cells, vectors, and
>strings.  And I'd like them to share the garbage collector.

Or you could write a single allocator with the GC-inline, and
include a parameter which specifies which of the three allocation
modes you're requesting, and then write three wrappers around the single
alloactor with your three allocation functions and their normal interface.

>I could always ignore the Glulx stack an use my own, but that would be
>slow and nasty, and I prefer to abuse as little of the VM as possible.

Aren't you already doing that according to point (1) above? As you
say, GC needs to refer to the live set of EVERY pending function,
i.e. "everything on the stack", and if glulx disallows looking outside
the current stack frame then you're need to do this all the time anyway.

Or, yet another alternative, you could not use Glulx as the target of
this compiler, since it sounds like Glulx is really not an ideal VM
for things like looking up the stack.

None of these suggestions sound like rocket science to me, but maybe
I'm missing something.

But allowing branches to common code from other functions is NOT the thingg
to change to get what you want.

SeanB
