>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 02:15 PM 5/29/2001 -0700, Hong Zhang wrote:
>> > we have a simple set of load literal, push/pop (multiple) registers op
>> > codes.
>>
>> There should be no push/pop opcodes. They are simply register moves.
DS> The one handy thing about push and pop is you don't need to go
DS> tracking the stack manually--that's taken care of by the push and
DS> pop opcodes. They can certainly be replaced with manipulations of
DS> a temp register and indirect register stores or loads, but that's
DS> more expensive--you do the same thing only with more dispatch
DS> overhead.
DS> And I'm considering the stack as a place to put registers
DS> temporarily when the compiler runs out and needs a spot to
DS> squirrel something away, rather than as a mechanism to pass
DS> parameters to subs or opcodes. This is a stack in the traditional
DS> scratch-space sense.
i agree with that. the stack here is mostly a call stack which
save/restores registers as we run out. with a large number like 64, we
won't run out until we do some deep calls. then the older registers (do
we have an LRU mechnism here?) get pushed by the sub call prologue which
then uses those registers for its my vars.
is the sub call/return stack also the data (scratch) stack? i think
separate ones makes sense here. the data stack is just PMC pointers, the
code call stack has register info, context, etc.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
