Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!howland.erols.net!netnews.com!newsfeed.nyc.globix.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: Z-Machine
Message-ID: <GGzFs6.4M4@world.std.com>
Date: Tue, 24 Jul 2001 14:48:06 GMT
References: <2xn57.49227$WS4.7531669@news6-win.server.ntlworld.com> <68067.56913$WS4.8617327@news6-win.s <tlptsqk315gn71@corp.supernews.com> <GGzBJ8.8y5@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 70
Xref: news.duke.edu rec.arts.int-fiction:90137

Sean T Barrett <buzzard@world.std.com> wrote:
>L. Ross Raszewski <lraszewski@loyola.edu> wrote:
>>The advantage of these is dubious; the memory most people run out of
>>is not string and routine memory, but byte-addressable low
>>memory. Increasing that requires changing the address size
>
>But if most low memory is used by objects, and if object data
>is always accessed via some sort of (object #, object data reference
>pair), then all that needs to be done is alter the object # ->
>data storage mapping so that it can address more memory.

Ok, I forgot about how Inform uses the veneer to implement
individual properties.

The lowest-hanging fruit I can think of after reading
the zspec and some of the Inform TM is the following
scenario:

   All arrays are constrained to start on word boundaries
      (even byte arrays)
   Each piece of property data starts on a word boundary
   All byte and word arrays are addressed using "word addressing",
      which allows 128K of dynamic memory

This would make "pointer arithmetic" on byte arrays impossible,
but I don't know whether people currently do that. (Pointer
arithmetic would lose the leading size information, but that
data isn't there for properties data anyway.) If you can't put
bytes or byte arrays into properties, you could leave byte
array addressing alone. (Or if you can, but the Inform library
never does, you could just abandon support for it.)

If property values are generally never one byte (and again that
would seem to be rare with Inform, since I don't even recall
the syntax to declare a byte property value), then if they
are typically two bytes, the property identifier might as
well be two bytes since you'd need to pad to align anyway, so
the current "common property" encoding that uses one byte in
most cases won't be useful. [This would expand common properties
from 3 to 4 bytes for each instance, sucking back up some
of that extra dynamic memory.]

If you're going to always have two bytes for each property
identifier in the property tables, you might as well stretch
the range of property IDs allowed, at which point this modified
z-machine might as well take over individual properties back
into its own property tables. This could use some sort of coding
that most of the time encodes property ID + size in 2 bytes,
much like the existing "most of the time in 1 byte", e.g. 12
bits for ID, 4 bits for size, and the largest size value means
"the real size is in the next byte".

One thing that's messy about taking over individual properties
is the current implementation of "class::identifier"; I don't
really understand what the reason for coding this into a
property identifier is, as opposed to just generating appropriate
code in the place where it's used. (I.e. do people pass around
thes identifiers and then attepmt to look them up on objects?)

All of this seems reasonably tractable to me. It might be
worth taking an existing large game and the Inform source
and seeing how much bloat you'd get. (It should also, I think,
shrink the code somewhat since some veneer calls could be replaced
with z-machine instructions.) But I'm not sure it's worth
the trouble unless this limit is really bugging people.
Personally I favor just switching to glulx. Finding nostalgia
in using the "same interpreter as Infocom did" when it really
isn't is a bit... strange.

SeanB
