>>>>> "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. 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. 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.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
