Matthias Horn <[EMAIL PROTECTED]> writes:
> > ....
> >the update continuation has both a return vector and a direct return
> >address, so any kind of return can be handled by the update frame.
> >....
> >
> But wouldn't this imply that each binding has to be compiled in two
> versions. One version for the vectored return and another for the
> direct return? In this case a polymorphic spark has to use always the
> version for the direct return and wouldn't be as efficient as an
> evaluation which was not sparked.
Nope - the code for the update frame return address is laid out like
this:
| return |
| vector |
| ------- |
| info |
| table |
| ------- |
| direct | <--- return address
| update |
| code |
. .
. .
A vectored return is performed by jumping to the address at Ret[-n-i]
where n is the size of the info table, and i is the constructor tag
being returned. Each entry in the vector table points to some code
that performs the update and returns using the same vectored return.
In this way, we can use *one* return address for polymorphic updates
and seqs/pars, without imposing a performance penalty.
Cheers,
Simon
--
Simon Marlow [EMAIL PROTECTED]
University of Glasgow http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key
