[z-machine] Fwd: [Inform mntce] The Z-machine and Informs 6 and 7

[samwyse]

Gee, that was easy.  OK, I'm subscribed now.

On 10/19/05, samwyse wrote:

I'm going to try to cross-post, but since I don't subscribe to the
zmachine list I may need someone to forward this for me.  I guess I
need to subscribe.  ;-)

On 10/19/05, Graham Nelson <graham at gnelson.demon.co.uk> wrote:
> On 19 Oct 2005, at 12:52, samwyse wrote:
> > At the
> > time, Graham said that I7 would use a lot of dynamic tables, but has
> > anyone verified that fact?
>
> It does use quite a lot of arrays, but in practice we seem not to be
> bumping into limits as much as I'd expected. That may be because
> we have a propensity to make uber-cool medium sized games
> rather than more plausible large-game designs, though. So at
> present I don't feel too bad about that, but it may be an issue
> again. I'm inherently skittish about making a .z9 design which
> nobody implements, and losing Z's greatest strength - its
> ubiquity.

The greatest strength of the current .z9 design is that is is almost
trivial to implement.  My CVS diff for frotz measures about 8KB, with
the biggest chunk supporting dictionaries that have different
resolutions from story-file to story-file.  (This feature was added to
better support authors of non-English storyfiles.  It's quite possible
that such games would comprise the bulk of future .z9 games.)  As I
recall, David Kinder was able to turn around a version of Windows
Frotz within a day of receiving the patches.

> That said, I currently have three preoccupations about Inform and
> the Z-machine:
>
> (a) I would like better and more transparent Unicode support.
> Ideally, I6 should read a UTF-8 input file and write a story file
> which an interpreter with one of the "big" fonts would simply get
> right. I've largely forgotten the issues involved, but I have a feeling
> that it isn't completely trivial, and there are awkward dictionary
> issues involved. I just feel that any 21st-century Z-machine ought
> to understand Unicode. This might need careful thought.

I really want Unicode support, but can't see any way to include it
without a radical redesign of ZCSII.  And that means a much larger
patch file, which is less likely to get migrated into existing
interpreters.  OTOH, better Unicode support would certainly also
assist authors of non-English games.  In either case, the fact that
.z9 supports strings of almost limitless size in high memory means
that Unicode could be encoded as poorly as one bit per word without
worrying about hitting any intrinsic limits.

[ blorb discussion deleted ]

> (c) The stack is annoyingly inaccessible in the Z-machine.
> The reason I7 still doesn't have long integers or floating-point
> (or lists, or proper string variables - though other issues also
> make trouble there) is that one can't store local copies of
> arrays on the stack without all kinds of horror.

Personally, I view the inaccessibility as a feature.  As Zarf has
pointed out, it means that the stack's performance can be optimized
without worrying about endian-ness issues.  That doesn't mean that
opcodes couldn't be added to perform Forth-like manipulations, but
those opcodes would make for a bigger patch file.

> I'm not sure I see this as being something remotely easy to
> do anything about - ultimately, we just have to go to glulx,
> I guess - but it's the most significant area where the limitations
> of Z have imposed limitations on I7.

A secondary design goal of .z9 was to keep its distance from Glulx.
For example, there are lots of PalmOS-based interpreters for the
zmachine, but few or none for Glulx (or TADS for that matter).  With a
small patch-size, I hope that .z9 would show up on such small devices
quickly.  What I don't see is a need to distort the zmachine
architecture to do things that other VMs already do better.

> > Inform doesn't support any of the really nasty
> > things that can potentially be done with/to properties and I'm not
> > aware of any programs that do so.
>
> I7 certainly doesn't actually rewrite property tables on the fly,
> but (like lots of I6 code) it does access property addresses
> and write to them as arrays at some indeterminate period
> later.

So be it.  That leaves moving the object tree elsewhere.  Personally,
I'm against that as well, but I think that it would be easy to
implement.  The primary design code for .z9 (in my mind, at least) was
not to support I7, but to better support a lot of non-English authors
who were hitting limitations of the zmachine.  .z9 doesn't allow that
many more strings to exist in a storyfile, but it does let them be
encoded as inefficiently as one may want them to be.  It frees up a
bit of low memory, but it allows the dictionary resolution to be
increased arbitrarily (which eats up a measurable fraction of that
freed memory).  The people who were looking for help with Finnish or
Swedish games seem to have dropped out of r.a.i-f, but I'd like .z9 to
be there if they or their countrymen ever return.