Quetzal 1.4 stack frame format

Hello all,

I have a question about the stack frame format described in Quetzal. part of the format describes how many arguments the current routine call is using, 0 - 7. However, the specification does not describe saving the arguments as part of the stack frame when another routine is called. It seems that saving the routine’s arguments would be important part of the routine’s stack frame?

Thanks,
Steve

The initial values of the arguments are not retained, but the current values of the locals are, as described in section 4.3.

Hi Dannii,

Thanks for the reply. Indeed, the spec does not call for saving the arguments of the routine but does call for saving the local variables and I suspect that the logic goes that the arguments are used once and can be discarded since I suspect that each opcode that requires arguments comes with its own argument values. So, in the case of routines, the arguments are used to initialize local variables. And as the routine progresses, different values for the arguments can be used for other opcodes like in the case of add, and, etc. But I find it odd that there are flags in the Quetzal 1.4 spec to state which arguments the routine started with but it appears that the flags do not appear to add value since the values of the arguments are not retained.

What is the purpose for the argument flags?

Thanks,
Steve

I think that permits the @check_arg_count opcode to work right after a restore? Not positive of this.

1 Like

Yeah, @check_arg_count is the only use case I can think of. And even then, using that byte to store the number of arguments supplied would be enough, because there’s no way I know of to supply (e.g.) the first and third arguments but not the second.

I’m not sure if anyone ever actually uses this opcode. But Infocom specified it, so the save format should support it.

The I6 veneer uses it to implement obj.prop() and pass along the correct number of arguments. So it’s pretty frequent in Inform execution runs, even though it’s only used in that one veneer routine.

Yeah, I asked why it stores it in such an odd format years ago.

There’s actually enough space to store the provided arguments count in the flags, as it only needs 3 bits. But it’s good that it didn’t, because the extra byte means the stack always has an alignment of 2 bytes.

Hi all,

Thanks for the discussion. I will carry on enjoying figuring out the z-machine and related specs.

Thanks,
Steve

It’s illegal to do so.
From section 4.4.3 of the Z-machine standard:
“Once one type has been given as ‘omitted’, all subsequent ones must be.”