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 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.
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.