Updating the Z-Machine Standard Documents

I strongly disagree. That requirement is vague and can be interpreted in multiple ways. For the two store ops, the requirement to be within dynamic memory indicates a possible error condition. But when that is triggered will be different depending on how you interpret the signedness of the operands, handle overflow, and with what bit precision your arithmetic is done in. For the other two ops, the requirement to stay within dynamic and static memory can still be smaller than 64K if the story file is also and suffers from the same problems as above.

Explicitly saying all math operations in those ops must be wrapped modulo 16-bit and the final result interpreted as unsigned before checking against the limits of dynamic memory or the story file removes any ambiguity and makes whether or not the operands are signed or unsigned completely moot.

4 Likes

In my ideal world, we would do the exact opposite and specify that addresses >64KB should not be wrapped to 16-bit. This would instantly allow games to address more than 64KB of static data, alleviating one of the Z-machine’s principal limitations while breaking few (if any) existing games.

In practice, of course, this would go against the Z-machine’s original design and be impractical for 8-bit terps to implement. A controversial compromise might be to specify this as recommended behavior only, with the understanding that any games relying on it may not run on all interpreters (as indeed is already the case).

In theory I agree, although that ship has sailed.

Breaking any existing games would be a good reason not to do it. I’m also not a fan of adding more behavior that is interpreter dependent.

1 Like

I would appreciate it if the whole document could be put on a single page. Right now it is always a bit tedious to find some information if you don’t already know where to look.

For print_obj it says:

Print short name of object (the Z-encoded string in the object header, not a property). If the object number is invalid, the interpreter should halt with a suitable error message.

However according to section 12. The object table the object’s short name is in the property header.

It is strangely worded.

The short name of the object is in the header of the property table, but is not itself a property.

Maybe this should be changed to

Print short name of object (the Z-encoded string in the object’s property header, not a property). If the object number is invalid, the interpreter should halt with a suitable error message.

1 Like