Dan Sugalski wrote: [ stack implementations ]
Well... we only really have three.
Control, User & Pad have the same stack engine. The register backing stacks and rxstack sum up to 5 more.
Pads shouldn't really be stacks, they should be plain linked lists. The register backing stacks, while implemented separately (which is just wrong) are really identical--the only difference is the size and type of the frames being stored. I'd have macro'd them up, but as I said I didn't quite have time, and it took less brain power to cut-n-paste the code. Sad, but true. The integer stack's separate on purpose, as it's supposed to be a high-speed thing for the regex engine to use, at least for the most part.
That leaves us three stack types: control/user, register backing, and integer stacks. The implementation of the backing stacks should be combined up into one chunk of macro's code so there won't be problems with cut and paste errors.
Pads and namespaces are singly-linked lists, which we need to deal with separately.
... The I/P/N/S stacks are all the same, the only reason they've got different code is because the elements are of different types and sizes. Macro-izing them would probably be in order, and the only real reason I didn't was that I was in too much of a hurry to do so. The integer stack's special-purpose, so that makes sense as well.
I'm, thinking of push/pop subs (or macros) for all stacks that (in case of subs) are inlined in the normal case, when no additional stack frame action is necessary. The slower and bigger frame handling part would be an external sub.
Inlining doesn't always buy you anything and sometimes makes things worse. Counter-intuitive, but nonetheless true. We'd be better off with a set of no-check push/pop ops that don't check on a whole lot of the stuff the ops do now, since pushing a register frame or control stack thing would be much faster if we didn't have to check for over/underflow or COW state.
Yes, comments do state this. So we need general COWable buffers plus some rework in stack code.
Yep.
Done.
Keen, thanks.
[ Coroutine stack & multithreading ]
But calling a coroutine may involve putting the coroutine's stack in place as well, which is where the interesting bits come in.
Coroutines as other subs might get called from different threads. So the Sub objects for a sub called from different threads are different (implying with separate stack items). The return continuation (presuming a common caller thread) would be the same.
I'm not sure yet how we're going to handle that, whether there'll be a lock taken on the coroutine PMC, or whether invoking it should COW the continuation in the coroutine. Arguably multiple threads shouldn't be able to be inside the same version of a coroutine at once.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
