Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!solaris.cc.vt.edu!news.vt.edu!netnews.com!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Glulx] branching to another function...
Message-ID: <GJEo84.1n1@world.std.com>
Date: Sun, 9 Sep 2001 17:21:40 GMT
References: <e61ef191.0109081452.45f636f9@posting.google.com> <Pine.OSF.4.30.0109090247090.13491-100000@vesuri.Helsinki.FI> <GJDE6C.3Bn@world.std.com> <e61ef191.0109082124.15f91f96@posting.google.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 64
Xref: news.duke.edu rec.arts.int-fiction:92402

Jon Zeppieri <97jaz@my-deja.com> wrote:
>*The single allocator approach will work, with a small efficiency
>penalty. The problem is that Scheme programs tend to allocate a lot,
>so the allocator should be as lean as possible.

Umm, but you're already paying a huge performance penalty by
outputting to a VM. Heck, you're paying a significant performance
penalty by outputting to a VM which is stack-oriented instead
of register-oriented. So an extra 10% on the the allocator doesn't
really seem worth worrying about.

>The "pre-allocate a
>p. continuation" idea does not work, as I've explained already.
>Actually, it could be made to work, if the pre-allocated p.
>continuation were large enough to hold a potentially full stack.
>I.e., it would be unreasonably large.  It would also be a special
>case.

Garbage collection is a special case. "Reserve some memory for
the processing you need to do when you run out of memory" is a
classic programming technique.

Also, you could easily set yourself a max stack size for pending
computations; saying "this expression is too complex to compile"
is a little goofy but not the end of the world, especially if
achieving it would require 64 levels of nesting which one could
argue is bad style anyway. Or the compiler could notice the
maximum stack depth used by any one routine, and output that
result as the size of gc-continuation to allocate.  Since the
size is likely to be under 64, it's not likely to be
"unreasonably large".

>I could also make my own evaluation stack and manage my own
>stack pointer, but that strikes me as almost, though not quite,
>equally ugly.

Yes, I agree, at that point you're really not using the glulx
VM in a practical manner. You'd have both size bloat and a huge
performance loss.

Yet another solution would be to have three allocation functions,
which if there isn't enough memory all tail-call to a single
allocator which does gc and then handles all three cases itself.
This could lead to yet more code replication, unless the only
difference between the allocators is the size of the item they
allocate.

Another thing you could do is have them all call the gc
and just live with the fact that their live data isn't exposed
to the gc--e.g. make sure the place where you're calling the
gc doesn't leave any surprising data hanging. (I'm not sure
what data it could, since you'd presumably just have traversed
a data structure representing free memory, and found nothing
sufficient, so what you could be pointing to, I don't know.)

Hey, if glulx doessn't allow branches between functions, how do you
do tail-call elimination? I can see that you could just call
and ignore the fact that it leaves stuff on the stack (since
none of that would be live), but it seems like you're eventually
going to stack-overflow... or does glulx have some kind of
"tail-call" opcode?  (Hmm, should go add that to my high-level VM
spec: "call and return".)

SeanB
