This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Richard Kelsey <kelsey@xxxxxxx>
> Pika-style conventions do not make those presumptions: there is a
> comprehensive abstraction barrier there between the Scheme value
> representations, the heap invariants, and the C code.
> The latter is far less restrictive on Scheme implementations.
> Yes, and more overhead for accessing Scheme values from C.
> It's a tradeoff. We made it one way and you would make it
> another.
To reiterate -- I'm not convinced, now that I've noted you require
GCPROtection of parameters in functions that may cause GC -- that
Pika-conventions actually have more overhead.
I don't see any really good way for us to prove it one way or the
other just now. The number of loads and stores is about the same
with either approach. Pika can get by registering fewer variables
for GC. In some interpreters, Pika's incessent indirection can be
eliminated in the bulk of cases.
They are at least awefully close. I wouldn't leap to the conclusion
that either is cheaper than the other.
-t