Leopold Toetsch <[EMAIL PROTECTED]> writes:
Not quite for this case. Or in theory yes, but... As calling the subroutine mustn't have any changes to the caller's registers, it's just simpler to save these registers that the subroutine might change.
But generating the save signature for a given sub is a compile time cost that only needs to be paid once for each sub and shoved on an I register
... once per sub per location where the sub is called from. But there isn't any knowledge that a sub might be called. So the cost is actually more per PMC instruction that might eventually run a PASM MMD. This is, when its done right, or ...
(which could, of course, be standardized).
Yes. saveall, which is really expensive.
... An MMD sub with a PASM
implementation simply looks at the appropriate register, saves the right
stuff, sets up a return continuation and has the interpreter invoke
it.
Well, that's exactly how it works now, with a bit differing in the meaning of "right stuff" :)
The work has to be done either way, but by arranging things so that everything looks like caller saves (and so that there is no MMD barrier to continuations) just seems to make the most sense. BTW, if it's a continuation barrier does that also mean it's an exception barrier?
It looks like caller saves. The saved range of register's can't change that view. If the caller or the called sub defines the saved register range does in no way change *how* registers are saved. They are saved by the C code that actually runs the PASM. And the PASM is run from C code. These are the "problems".
And WRT continuation barrier: I already have said: if we really need that (an opcode function "jumps" somewhere) then its possible. On each enter of the run loop a setjmp(3) is done, which is also the base for throwing exceptions from within an opcode function. There are no barriers, AFAIK.
leo
