At 02:50 PM 9/17/2001 -0400, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 02:06 PM 9/17/2001 +0100, Dave Mitchell wrote:
>
> >> If we have one generic stack with all sorts of things on it, why not
> >> treat it as a stack of objects, with each object "knowing" what to do
> >> with itself when popped? Or more prosaically, for each "thing" pushed
> >> onto the stack (register set etc), we also push a pointer to a function
> >> that gets called when the thing is popped. ie like the Perl 5
> >> savestack, but we push a fn pointer rather than a SAVEt_* constant.
> >> This gives us flexibility + extensibility, but may slow us down.
>
> DS> I'm currently working on the assumpution that each thing pushed
> DS> gets a type attached to it, and that type will be dealt with
> DS> appropriately when things are popped. I wasn't thinking of going
> DS> as far as putting a function pointer in there, but that's not an
> DS> unreasonable thing. Dunno whether it'll be faster or not, but
> DS> it'll certainly be interesting.
>
>it is not a bad idea if only for simplifying stack management. but i
>feel it may be a bottleneck with the overhead of checking each item
>during push/pop.
True, though we can either vector through the function pointer or have a
switch using the type.
>dan had mentioned earlier having multiple stacks with
>each one dedicated to certain types of data. they could share much of
>their code (since our stacks will be segmented that is useful) but they
>would be called explicitly for each type of data. when a sub call op is
>executed, it will use the call stack and probably the argument
>stack. inside a sub, getting free registers will use the register
>stack, etc.
Hmmm. I'd not actually considered an argument stack--I was assuming (bad
Dan! :) that we'd just use the various registers.
The stacks I've been thinking of are:
*) The register stacks
*) The general stack
Might be a bit restrictive, though it does make unwinding things easier.
>the above proposed idea would add a parameter (stack/data
>type or object) to each stack call and also require a dispatch (object
>or whatever) to handle a proper pop. it would be an interesting
>experiment to see the differences in speed and code simplicitly.
I'm not hugely worried about speed here, as I'm not sure if we will be
doing all that much pushing and popping. We'll also need to save the type
anyway, so the GC can walk the stack and find any live PMCs on it.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
