On Sun, Jun 12, 2005 at 03:40:55PM -0600, Curtis Rawls wrote:
> I also do not see the wisdom of reducing continuations to just a GOTO.
It really isn't just a goto, at least, not a hardware-CPU-style goto.
By virtue of Parrot's registers living in memory attached to the
activiation record, switching control to a saved activation record
automatically restores all the registers. Automagically, even.
I've talked this over extensively with Piers (on IRC), Autrijus, and
Leo, and I'm now convinced that switching to a saved activation
record, along with the register contents still in it, is enough.
Granted, the register allocator[*] will still need to learn that it
can't use any given register for incompatible purposes across
subroutine call boundaries (or across labels). But given the new
larger cheeze-its^Wregister frame, that's no problem.
> Continuations should have all the abilities of a function, with the
> additional abilities of returning its state, in the form of its
> activation record, and being reinvoked with said activation record.
> The activation record stores all info about the state of the function
> (saved registers, calling function, PC, etc). Maybe think of it as a
> snapshot of the function's state.
Quite. My "glorified goto" description neglected a key difference
between the Parrot VM and a real CPU: a goto in a real CPU does not
restore registers, while switching activation records in Parrot does.
[*] the PIR register allocator, that is, which may under certain
circumstances realize that $P30 and $P35 have disjoint lifetimes
and are never used across a function call, and therefore can be
assigned to the same actual P register (e.g. P20)
--
Chip Salzenberg <[EMAIL PROTECTED]>
