Now we are placing arguments or return values in registers according to
PDD03 and the other end has immediately access to the placed values,
because the register file is in the interpreter.

With the indirect addressing of the register frame, this argument
passing is probably the most costly part of function calls and returns,
because we have to copy the values. One way to reduce this copying cost
could be to make argument passing more explicit. E.g.

    $P0 = get_caller 1        # 1)
    copy_args_from $P0        # 2)
    copy_args_from_caller -1  # all in one

or
    I5 = $P0[5]               # 3)
    P5 = $P0[-5]

ad 1) As call and returns are basically the same, this is usable for
both directions. The integer argument holds the level - positive is up
the call chain, -1 is the last called sub for return value access.
During startup a dummy sub is created for the command-line args access.
Such an opcode or functionality is needed for introspection and
backtraces too.

ad 2) The all in one would be the usual emitted opcode. But, and that's
the import thing, functions returning values in *void context* could
just omit this opcode and avoid the copying.

ad 3) Could be useful to access arguments, only when needed to reduce
register allocation stress, or to access only parts of arguments.

Finally, making argument passing more explicit could be needed anyway.
Python is AFAIK passing a value tuple at least in the general case for
star_args. Converting values in registers to and from tuples could be
done by a python-specific version of such an opcode. And there are still
named arguments, which we don't really cover ...