> -----Original Message----- > From: Melvin Smith [mailto:[EMAIL PROTECTED] > > I tried this, and there was a distinct slowdown on accessing the regs > through the dereference. Dan and I debated this because I had the same > idea, but after profiling I proved Dan right. I think it is best > optimized to > the common case which is register access, not context switches.
However now the registers are no longer in the Parrot_Context struct, so it may be worth revisiting this ... > -----Original Message----- > From: Leopold Toetsch [mailto:[EMAIL PROTECTED] [snip] > So all these subroutine types should have probably this structure: > > typedef struct Parrot_Sub { > struct Parrot_Context ctx; > opcode_t *address; > } * parrot_sub_t; Or a PMC with SELF->data pointing to a Parrot_Context struct and SELF->cache.int_val holding the address? > On *construction* they would do: > > all: save_context(); // like in new_continuation > sub, coro: push_current_lexpad_on_own_ctx(); // like new_coroutine [snip] Here is what I think. All of these things need an address and some amount of context which is saved on construction and restored on invoke. The different types the context to be saved and restored[1]: sublite[2]: none - just address sub: pointer to a lex pad coroutine: whole Parrot_Context[3] - i.e same as ... continuation for cps approach: whole Parrot_Context[3] Sound correct? -- Jonathan Sillito [1] This is not considering other context information that Dan has been talking about. [2] This does not exist but could if we wanted to support subs that are not closures - many are not. [3] This is in the worst case, and I would like to see variations that are more optimized.
