Hi Andy, thanks for the update!  Exciting times for Guile :)

On 08/02/2012 10:29 AM, Andy Wingo wrote:
> Instead I'd rather just use Dybvig's suggestion: every call instruction
> is preceded by an MV return address.  For e.g. (values (f)), calling `f'
> would be:
>
>      ...
>      goto CALL
> MVRA:
>      truncate-and-jump RA
> CALL:
>      call f
> RA:
>      return
>
> So the overhead of multiple values in the normal single-value case is
> one jump per call.  When we do native compilation, this cost will be
> negligible.  OTOH for MV returns, we return to a different address than
> the one on the stack, which will cause a branch misprediction (google
> "return stack buffers" for more info).

I wonder if it might be better to avoid this branch misprediction by
always returning to the same address.  Upon return, a special register
would contain N-1, where N is the number of return values.  The first
few return values would also be stored in registers (hopefully at least
two), and if necessary the remaining values would be stored elsewhere,
perhaps on the stack or in a list or vector pointed to by another register.

In the common case where a given call site expects a small constant
number of return values, the compiler could emit a statically-predicted
conditional branch to verify that N-1 is the expected value (usually
zero), and then generate code that expects to find the return values in
the appropriate registers.

On some architectures, it might also make sense for the callee to set
the processor's "zero?" condition code as if N-1 had been tested, to
allow for a shorter check in the common single-value case.

Of course, the calling convention can be chosen independently for each
instruction set architecture / ABI.

What do you think?

     Mark