On 2010-4-3 12:02 PM, Mark Cave-Ayland wrote:
[...]
It doesn't seem too clever. The way I've interpreted the number of
returned parameters field in the CIF parameter block is that it's the
maximum number of arguments the client would like returned. The
original spec isn't clear whether the number of returned items is
specified by the caller or set by the BIOS CIF implementation on
return. But at least we can correct for it by checking the stack depth.
Maybe Tarl has some more insight on this?
My interpretation of the spec is that N-args and N-returns *define* the
number of arguments taken and returned. If the called method generates
a different number of returns than the caller asked for, the interface
must either generate or discard the additional values.
In section 6.3.2.6 of 1275, for the general case "interpret" call, we
see:
N-args and N-returns are stored in the argument array and may be
different for different calls to interpret. If the number of items X
left on the Forth data stack as a result of the execution of cmd is
less than N-returns, only stack-result1, ..., stack-resultX are
modified; other elements of the returned values portion of the argument
array are unaffected. If X is more than N-returns, additional items are
popped from the Forth data stack after setting stack-result1, ...,
stack-resultQ so that, in all cases, the execution of interpret results
in no net change to the depth of the Forth data stack.
This is specific to the "interpret" call (and also in "call-method"),
but it suggests the approach that the caller is not required to
precisely match the called routine.