I missed this discussion I see, but for what it's worth, the patch I
submitted earlier in the week introduced a continuation pmc that does
**not** save or restore the registers. The old continuation pmc that saved
(including the registers) everything has been renamed to
completecontext.pmc.

On the other hand I like the idea several types of continuations including
one that saves and restores half of the registers.

Finally if the registers are never to be saved as part of the context, we
should reorganize the relevant structs so that the registers are not part of
the Parrot_Context struct.

Jonathan Sillito

> -----Original Message-----
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> Sent: June 12, 2003 4:11 PM
> To: Luke Palmer
> Cc: [EMAIL PROTECTED]
> Subject: Re: Context, continuations, and call speed
>
>
> At 5:01 PM -0600 6/12/03, Luke Palmer wrote:
> >  > At 4:28 PM -0600 6/12/03, Luke Palmer wrote:
> >>  >  > Okay, at the moment I'm working on getting an implementation of
> >>  >>  classes and objects working. I'm also taking a look at
> calling speed,
> >>  >>  as I'd really like to not suck with our call times. :)
> >>  >>
> >>  >>  First off, the core stuff looks good. I'd not really looked at it
> >>  >>  until now, but now that I have, well... good job folks. I put in a
> >>  >>  minor tweak that may or may not speed things up
> (basically checking
> >>  >>  for the COW flag on stack chunks and bailing on the walk up if
> >>  >>  they're already marked) depending on what's resident in the L1/L2
> >>  >>  cache. We'll see.
> >>  >>
> >>  >>  Second, I see that the registers themselves are in the context
> >>  >>  structure. I think this may be a good part of our speed
> problem with
> >>  >>  taking continuations. Now, continuations should *not* restore the
> >>  >>  registers, so this strikes me as an incorrect thing to
> do, but before
> >>  >>  I twiddle the context structure some and remove them, I
> want to check
> >>  >>  and make sure that there's not a good reason to have them in.
> >>  >
> >>  >Well, aren't the registers really part of the context?
> >>
> >>  Nope. If they were, there would be no way to return data from a
> >>  function. The return values go in the registers, remember, and we
> >>  return to the caller by invoking the continuation it passed into us.
> >
> >But they really are, honest.
>
> No. No, they aren't. Registers are really data, so arguably a
> continuation restore shouldn't restore *any* of the register stacks.
> That'd make things rather... odd, so we're not doing that. I may
> regret it in the future, of course.
>
> Continuations are supposed to save only control information, not
> data. Registers are data. (And so far as I know, no system that does
> continuations saves register contents for restore, since there'd be
> no way to pass data back and forth)
>
> >Are the register stacks saved with the continuation?
>
> Yes, of course they are.
> --
>                                          Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski                          even samurai
> [EMAIL PROTECTED]                         have teddy bears and even
>                                        teddy bears get drunk
>

Reply via email to