How much stack space does the Z-Machine need?

[Dannii]

For ZVM I’m considering shifting to using a single combined call stack and program stack, stored natively using the Quetzal format. JS doesn’t allow typed arrays to be resized, so expanding the stack at run time would be non-trivial.

What’s the current best wisdom for how big the stack should be for I7 games?

[zzo38]

I don’t know about I7 (which probably requires more than ZIL), although perhaps you could test it. ZORKMID (Zork Machine Interpreter And Debugger) includes calculation of stack highwaters, but it only includes ZIP and not XZIP, and can’t make the calculation specifically for Quetzal (although adding it may be possible).

For Famizork I have limited it to 256 entries for data stack and 128 entries for call stack (locals for calls other than the current function are placed on the data stack); I think Infocom’s implementations on 6502-based computers have a similar limit. My own JavaScript implementation (which is public domain) does not store the stack in a typed array, but it does store the Z-machine addressable memory in a typed array. When saving it will automatically calculate the size of the needed typed array and save all data in it that will be needed to restore (the front-end should then save the contents of that typed array somewhere, possibly compressing it first).

It is true JavaScript has no realloc(), although it should not be too difficult to make one if you really need it.

[DavidK (David Kinder)]

Graham’s original note (available here http://mailman-new.greennet.org.uk/pipermail/inform-maintenance/2006-March/001661.html) at the time of the first public release of Inform 7 says

The ZMSD does not formally specify a size for the stack, only a minimum likely to make Infocom story files playable. Moreover, the ZMSD does not specify how the stack is to be stored: on most interpreters it holds both explicitly stacked values and also stack frames of routines, but Zoom keeps its stack frames elsewhere, for instance. This unfortunately means that story files crashing out on one interpreter may work fine on another.

We ask that interpreter-writers raise the stack size as far as sensibly possible. On genuinely small machines, this could be a waste of memory, but at any rate please ensure a stack of no lower than 16K in size, and if memory is not a concern then please allow 64K or more, just in case.

Windows Frotz has a 32K stack, and I’m not aware of any game ever overflowing this.

[zzo38]

Perhaps allocate 64K then. A JavaScript implementation that separates back-end from front-end could also allow a parameter to control stack space; the front-end can then fill it in depending on the I/O layer. For example, with Node.js you can use v8.getHeapStatistics() and so on (although this may not work perfectly); as far as I know no such thing is provided in HTML (although I do not generally script HTML and do not know a lot about it).

I am not going to change Famizork and so on; you shouldn’t need large amounts of stack space if reasonably programmed (I think 16K is too much and 64K is way too much, but maybe I7 requires it, so implement what you need).

Is ZORKMID the only implementation that keeps track of stack highwaters?

[Dannii]

64K sounds good then. Any JS implementation with Typed Arrays should have enough memory. Even basic phones have a decent amount of RAM now.

But I should also put a cap on the undo saves…

[zarf (Andrew Plotkin)]

The last time I ran into Z-machine stack size limits was with Heliopause, which can get several layers deep into “instead try actioning…” statements. My notes there say that 1K was definitely too small, and 60K was definitely enough. I didn’t map out exactly where the usage fell between those extremes.