-----Original Message----- From: Melvin Smith [mailto:[EMAIL PROTECTED]
I tried this, and there was a distinct slowdown on accessing the regs
through the dereference.
However now the registers are no longer in the Parrot_Context struct, so it may be worth revisiting this ...
Yep. Though, when register access had a slow down, ctx member access will have too - probably.
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?
Dunno yet, but could be probably.
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?
The primary question is: Why do we save and restore what part of context. For restore (the continuation part) it seems clear:
[ I don't know the answer, but guesses are: ]
- stack pointers: to be save against unpaired push/pop
- opfunc tables: when a different languages changes them on the fly (not yet)
WRT saving:
A non nested sub doesn't have parents lexicals. So the Sub_lite thingy should be ok.
OTOH: we might put distinct stacks in place. If we don't, these stacks might grow very deep. This would have linear function call performance penalty going with the call depth, as we over and over have to stack_copy more and more stack frames.
leo
