[z-machine] So-called bad practice in the Z-machine

[Amir Karger]

--- Thomas Thurman <marnanel@marnanel.org> wrote:
> On Thu, 18 Sep 2003, Amir Karger wrote:
> > So my question is (finally!), if we grant that the programs I
> > output won't follow the 1.0 spec, how bad is that? How many 
> > games abuse the Z-machine this way? 
> 
> Since your program has the special benefit of being able to review
> the
> entire story before translation, though, you could implement the
> subroutine calls as function calls in the general case, and either
> have a
> special case for subroutines which branch to other subroutines, or
> just
> make the translation fail in those cases.

I think I'll do the easiest, and just let the output program fail when
they try to run it, and maybe list in the README what things will not
work when translated.

As far as "modifying tables in dynamic memory without using opcodes
like
set_attr" that I mentioned last time, I realized that I need to embed
the entire dynamic memory into my program anyway, for things like
restore. (I'll probably uuencode it or something just to be pretty.)
And I'll need to repack things for save. 

So since I have the string there already, and especially given Ross'
email, I'll need to implement loadw to use that string. But once I've
done that, I'll need to special-case the loadw implementation to work
differently depending on whether the address given is static or
dynamic. At that point, why not embed the static memory, too, and
address everything via that string? The string is still guaranteed less
than 64K, which isn't a big deal for most computers & languages
nowadays. I'm not going to embed the entire high memory, though. Seems
wasteful, although it means I won't be able to implement checksum
verification and could potentially get a bit big for certain languages
running on, say, Palms. I think it's safe because high memory isn't as
accessible to the Z-machine, except for print_paddr, which AFAICT
doesn't talk to low memory. (Pardon me if I'm using these terms
incorrectly.)

It'll be less pretty using byte access for all the object stuff, but
that's life. (If I got really fancy, I could implement it with objects
and just have the methods do the byte access on the big string, but the
truth is, who's really going to look at the output code anyway? I did
realize that with the embedded string and the much more verbose code,
it'll be WAY bigger than a Zfile. OTOH, it'll compress much better.)
Also, it means I can steal more code from Games::Rezrov.

I'm making some progress on the Z-machine test file, btw. It's testing
the basic stuff like arithmetic and subroutine calling a bit more
heavily than nitfol's tests did (and will hopefully get even better if
I get less lazy). But it's not testing any property/object stuff yet
since I still didn't implement that. Once I do get that stuff covered,
maybe I'll post the test file for comments. (I will mention that the
Z-spec description of lsr vs. asr is NOT entirely clear, which cost me
several hours trying to figure out how I was supposed to implement it:
and it didn't help that different Z interpreters fail different nitfol
tests! Also you probably all know that the Z-spec says "stores" instead
of "loads" in the definitions of a couple of the load opcodes.)

Yours verbosely,

-Amir


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com