Re: [MIT-Scheme-devel] R7RS and values.

[Matt Birkholz]

I just pushed a commit to the new multiple-values branch that implements
REFLECT_CODE_MULTIPLE_VALUES.  Most of the smarts still end up in
Prim_values, the stack magician.  The reflection(?) improves the
performance of the tests (aka tests/check.scm) dramatically.

With a Prim_call_with_values that longjmps out of compiled code at
every opportunity, (load "check") was 124% slower (taking more than
twice as long!).  With a reflect code, it is only 20% slower.

I'm not sure why tests/check.scm hammers so on poor Prim_values.  The
compiler was relatively unaffected by ALL of this, but it uses its own
implementation of call-with-values, calling it transmit-values and
implementing it in compiler/base/mvalue.scm.  I replaced
transmit-values with call-with-values but realized later that I really
didn't need to.

I do not have SVM builds working yet, but I don't expect that will be
a problem.  Is tools/patch.scm a problem?  Too kludgerrific?  How
SHOULD I train a 9.2 build host?

Using Prim_values may be 20% slower than the old, closure-based,
restricted implementation, but maybe it is good enough?  Normal
continuations are unaffected.  The restriction is removed and r7rs
mollified.

Is there something more that can be done?  Is the 20% slow-down mostly
the unavoidable cost of using primitives, crossing the C / Scheme
divide?