> From: Taylor R Campbell <campb...@mumble.net>
> Date: Fri, 14 Oct 2016 20:10:38 +0000
>
> Date: Fri, 14 Oct 2016 12:25:12 -0700
> From: Matt Birkholz <m...@birchwood-abbey.net>
>
> Did I hear that VALUES might not be terribly expensive nor difficult
> to implement? Taylor suggested a simple trap is all we need(?).
> I have tried to work out the details here.
>
> What I experimented with several years ago was to add not another
> trap, but another return code. (It will require additional work in
> the compiler, since the four {interpreter, compiler}^2 paths from
> callee to caller are all slightly different.)
OK. I just pushed a multiple-values branch with a commit that does
basically what you describe. It adds the two primitives (VALUES and
CALL-WITH-VALUES) and an RC_MULTIPLE_VALUES handler that does the
stack manipulation.
Disabling 9.2's expansion of VALUES and CALL-WITH-VALUES forms allowed
a cross-runtime to be built, and a couple small fixes (procedures that
need to pass along multiple values) got the cross-compiler running, so
it builds and runs...
...rather slowly. This perhaps is where a REFLECT_CODE_MULTIPLE_
VALUES must come to the rescue (to avoid many longjmps?).
I never did find a need to futz with the compiler. Presumably you
meant the compiled code interface, possibly by adding a reflect
code...
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
